INFO: Cómo Visual Basic 3.0 identificadores de seguridad establecido por Microsoft Access

Seleccione idioma Seleccione idioma
Id. de artículo: 105990 - Ver los productos a los que se aplica este artículo
Este artículo se ha archivado. Se ofrece "tal cual" y no se volverá a actualizar.
Expandir todo | Contraer todo

En esta página

Resumen

Visual Basic versión 3.0 incluye el motor de base de datos de Microsoft Access. Visual Basic contiene la sintaxis para manipular una base de datos Microsoft Access en casi cada forma en que Microsoft Access puede. Una excepción importante es en el área de seguridad. Sólo Microsoft Access puede establecer o modificar opciones de seguridad (como ID de inicio de sesión y contraseñas para el sistema) y establecer o modificar permisos en objetos específicos de una base de datos determinada.

Versión 3.0 de Visual Basic contiene dos instrucciones (SetDataAccessOption y SetDefaultWorkspace) que permiten una aplicación de Visual Basic para satisfacer el mecanismo de seguridad que implementa Microsoft Access e inicie sesión con código de Visual Basic. Mediante estas instrucciones, puede tener los permisos concedidos a un usuario determinado.

En este artículo explica los mecanismos de seguridad aplicables a la versión de Visual Basic 3.0 y el programador de Visual Basic. Las capacidades de seguridad completa de Microsoft Access son fuera del alcance de este artículo.

Para obtener una descripción completa de las capacidades de seguridad de Microsoft Access, consulte el siguiente artículo de Knowledge Base:
122036WX1051: Asistente para seguridad y la nota de App. documento 2.0

Más información

La seguridad se implementa en dos partes:
  • Cada usuario y grupo tiene un código de identificador (SID) de seguridad único.
  • Ese código de SID se almacena en la base de datos along with los permisos asociados para ese SID.
Las dos secciones siguientes proporcionan los detalles.

Cada usuario y de grupo tienen el identificador exclusivo de seguridad (SID)

En Microsoft Access, cada usuario y de grupo tienen un identificador de seguridad (SID). El SID es una cadena binaria que identifica inequívocamente el usuario o grupo. Cuando un usuario inicia sesión, si desde el cuadro de diálogo Inicio de sesión en Microsoft Access o desde código en Visual Basic (que se muestra más adelante en el artículo), el motor de Microsoft Access lee la tabla MSysAccounts de la base de datos System.MDA. Esta base de datos se crea sólo por Microsoft Access y se creará uno nuevo (vacío) si se elimina la copia original.

Nota: Si se elimina accidentalmente la System.MDA original, todos los SID únicos se pierden. Por lo tanto, también se pierde todo posibilidad de tener acceso a bases de datos protegidas. Por lo tanto, es una buena idea realizar una copia tanto en la base de datos como en el archivo System.MDA en lugar de seguridad cuando se han establecido los permisos en la base de datos.

Cuando se inicia una sesión, el usuario proporciona el nombre de usuario (no distingue entre mayúsculas y minúsculas) y la contraseña (se distingue entre mayúsculas y minúsculas). Si el nombre de usuario y contraseña son correctos, el SID del usuario se recupera y se guarda en una estructura interna para el motor. La contraseña se utiliza sólo para validar el usuario. A partir de este punto, una vez que el usuario pasa a ser un usuario validado, la contraseña no tiene efecto en la seguridad.

Aquí es un punto clave que pertenece al comportamiento de Visual Basic. De forma predeterminada, el motor de Microsoft Access intenta validar el usuario y la contraseña de administrador y "" respectivamente. Versión 3.0 de Visual Basic, sin ningún código, enviará esta combinación de teclas al motor de Microsoft Access de forma predeterminada. Esto significa que, incluso sin el uso de las instrucciones relacionadas con la seguridad de Visual Basic, el programa de Visual Basic obtendrán admisión a la base de datos, si el usuario "Admin" del grupo Administradores no ha tenido su contraseña cambiado el valor predeterminado de ninguno ("").

Una vez iniciada la sesión, se recupera el SID del usuario. Este SID se utiliza para todas las operaciones posteriores dentro el motor de Microsoft Access.

El SID se almacenan en la base de datos System.MDA

El SID se almacena en la base de datos. Por lo tanto, todos los permisos concedidos a un determinado usuario o grupo también se almacenan en la base de datos, asociada al SID único.

Se abrirá otro punto clave relativas al comportamiento de Visual Basic. El programa de Visual Basic se obtener acceso a la base de datos y tiene permisos completos, seeming para omitir el mecanismo de seguridad Microsoft Access si se cumple alguna de las siguientes:
  • El programador de Visual Basic no ha tomado la ubicación de la System.MDA base de datos en la cuenta en el código del programa.
  • El usuario "Admin" no ha tenido su contraseña alterado desde el valor predeterminado de ninguno ("").
Esto se produce porque el comportamiento predeterminado del motor de Microsoft Access y Visual Basic. El efecto combinado es permitir la entrada a la base de datos y sus objetos por el código de Visual Basic.

La lista de los tipos de objeto de Microsoft Access son: tabla, consulta, formulario, informe, macro y módulo. De ellas, sólo los dos primeros son accesibles desde código de Visual Basic, por lo que el resto pueden omitirse de esta explicación.

Las siguientes dos secciones explican cada uno de los dos Visual Basic seguridad relacionadas instrucciones (SetDataAccessOption y SetDefaultWorkspace). Las dos instrucciones están diseñadas para proporcionar una opción de System.MDA archivos y entradas de inicio de sesión para una base de datos de Microsoft Access, con seguridad establecen por Microsoft Access. Siga estas dos secciones es una sección que relaciona las dos instrucciones en el comportamiento del motor de Microsoft Access con respecto a la seguridad.

Instrucción SetDataAccessOption--Comportamiento y la sintaxis

SetDataAccessOption tiene los siguientes parámetros:
   SetDataAccessOption option, value

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

Por ejemplo:
   SetDataAccessOption 1, "E:\VBPROJ\MY.INI"
				

En el archivo DATACONS.TXT proporcionado en la raíz del directorio \VB, se define una constante para este valor:
   Global Const DB_OPTIONINIPATH = 1
				

SetDataAccessOption establece el nombre y ruta de acceso archivo de inicialización (ini la aplicación del). Archivo .ini de la aplicación sólo surte efecto cuando se utiliza SetDataAccessOption antes de la funcionalidad de acceso a datos se carga y inicializada. Una vez inicializado el acceso a datos, esta configuración no puede cambiarse sin salir primero de la aplicación. El valor es una expresión de cadena. Para la opción DB_OPTIONINIPATH, el argumento de valor contiene una expresión de cadena proporcionando la ruta de acceso y nombre de archivo de inicialización (ini la aplicación). Archivos de inicialización se almacenan normalmente en directorio \Windows del usuario y tienen el mismo nombre que el archivo ejecutable, pero con una extensión .ini. Utilice esta instrucción sólo si el archivo de inicialización de la aplicación tiene un nombre diferente o está en un directorio distinto del directorio \Windows.

La instrucción SetDataAccessOption no es necesario al ejecutar el proyecto de Visual Basic en el entorno VB.EXE si el archivo VB.INI (en el directorio \Windows) contiene las líneas siguientes:

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

Nota: la ubicación real de la System.MDA no es significativa siempre que Microsoft Access y Visual Basic tienen una entrada que señala a la System.MDA compartirán. La instrucción SetDataAccessOption no es necesaria si el archivo .exe de la aplicación tiene su propio archivo .ini en el \Windows y los archivos .exe y .ini comparten el mismo nombre.

Instrucción SetDefaultWorkspace--Comportamiento y la sintaxis

SetDefaultWorkspace tiene los siguientes parámetros:
   SetDefaultWorkspace username, password
				

Si esta instrucción queda, Visual Basic se enviarán el equivalente de la línea siguiente al motor de base de datos de Microsoft Access que se incluye con Visual Basic:
   SetDefaultWorkspace "Admin" , ""
				

Esta instrucción tiene el efecto de obtener a un SID válido y obtener entrada para todos los objetos tabla y consulta de la base de datos.

Relación entre Visual Basic y seguridad de Microsoft Access

Para comprender la relación entre la seguridad de Visual Basic y Microsoft Access, debe comprender el mecanismo de seguridad de Microsoft Access. Ésta es una explicación detallada para beneficio de los programadores de Visual Basic que no ha utilizado ampliamente Microsoft Access. Hay una jerarquía de permisos en Microsoft Access. En el nivel superior, hay grupos. Dentro de un determinado grupo son usuarios. Para conceder selectivamente permisos a usuarios concretos, todos los permisos deben primero anular la selección o quitados el grupo de los usuarios. A continuación y sólo a continuación, pueden permisos concedidos o revocados para usuarios individuales.

Permisos enumerados para un usuario individual se denominan permisos Explicit. Los permisos establecidos para el grupo que contiene la cuenta de usuario se denominan permisos implícitos. Permisos implícitos tienen prioridad sobre permisos Explicit.

Puede utilizar el menú seguridad para establecer permisos en Microsoft Access después de que se ha abierto una base de datos y el usuario ha iniciado sesión. En el menú seguridad, elija permisos para asignar permisos en cada objeto de la base de datos, lo que en Visual Basic significa la tabla y consulta objetos.

Por ejemplo, si había un grupo en Microsoft Access, base de datos nombre analista que contiene los usuarios Juan y Ana y desea limitar sólo Juan para leer datos y conceder a Ana permisos completo, siga estos pasos:
  1. Inicie sesión en Microsoft Access como un usuario en el grupo de administradores. Por ejemplo, escriba administrador o Fred.
  2. En el menú seguridad, elija permisos (ALT S P).
  3. Objetos de tabla son el tipo predeterminado. Seleccione el nombre de la tabla que desea establecer permisos en. Por ejemplo, seleccione TestTbl.
  4. Establezca la opción en el marco de usuario o grupo a grupos. A continuación, haga clic en la lista del cuadro combinado hacia abajo y haga clic en analista seleccione ese grupo.
  5. Desactive todas las casillas de verificación para revocar todos los permisos para el grupo completo.
  6. Cambie el botón de opción de la lista volver a los usuarios y seleccione Bob. Desactive las casillas de verificación para todos los permisos de Bob.
  7. Seleccione Ana en la lista y Active la casilla de verificación permisos completo.
  8. Haga clic en el botón Asignar para aplicar los cambios a la tabla.
En este punto, suponga que tiene un programa de Visual Basic que contenga el código siguiente en el evento de carga del formulario:
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
				

Aquí se incluyen varios escenarios para ilustrar la relación entre Visual Basic y Microsoft Access Security:

ESCENARIO uno: en este caso, no hay ninguna referencia a la ubicación del archivo System.MDA. Windows y el motor de Microsoft Access son no se encuentra el archivo .ini con la sección [Options] enumerada anteriormente en este artículo. Por lo tanto, se omite el System.MDA y Visual Basic valor predeterminado es su combinación de usuario y contraseña predeterminada ("Admin", ""). Sin embargo, anteriormente, la contraseña predeterminada para la administración de usuario se cambia para algo distinto "". Además, se han revocado todos los permisos para los administradores de grupo y el usuario "Admin" en el grupo de administradores. Por lo tanto, se produce el siguiente error de Visual Basic en el punto 2:
Couldn't Read; no Read Permission for Table or Query 'f)) '

Ha cerrado la puerta trasera a Visual Basic y cualquier aplicación de Visual Basic intenta omitir los inicios de sesión en el archivo System.MDA.

ESCENARIO TWO: en este caso, porque invocar la instrucción SetDefaultWorkspace sin tener ningún puntero en el archivo System.MDA, el motor de Visual Basic Microsoft Access brujas para el archivo System.MDA y, al no encontrarlo, ofrece el siguiente error en el punto 0 en el código:
No se pudo encontrar el archivo 'SYSTEM.MDA'

Nota: Los errores producidos en ambos escenarios uno y dos son los mismos como podría ocurrir si el archivo System.MDA se ha movido, cambiado de nombre o eliminado.

ESCENARIO tres: en este caso, indica el motor de Visual Basic Microsoft Access en el que reside el archivo System.MDA pero no proporciona una combinación de usuario y contraseña. Por lo tanto, de nuevo, Visual Basic proporciona la combinación del usuario y contraseña sólo sabe ("Admin", ""), que ya no es una combinación válida porque se ha agregado una contraseña a la cuenta de usuario administrador. Como resultado, Visual Basic proporciona el siguiente error en el punto 1 en el código:
No es un cuenta válido o contraseña.

ESCENARIO FOUR: en este caso, se proporciona ambos parámetros correctamente. Por lo tanto, ya que le asignó Bob permisos "Leer datos", así como "Definiciones de lectura" para permitir el acceso de Microsoft Visual Basic motor para leer, la aplicación de Visual Basic imprime los dos primeros campos del primer registro de la tabla denominada TestTbl.

Si repite los cuatro escenarios con el usuario de Ana, todo sería el mismo. Sin embargo, Ana podría ir más allá y modificar la estructura de la tabla y los datos. Recuerde que primero seleccionó los analistas de grupo y revoca todos los permisos. A continuación, ha agregado nuevo todos los permisos a Ana, pero sólo definiciones de lectura y datos se agregaron a Bob.

Nota: El grupo de administradores tiene especial importancia con respecto a la seguridad. Esto se aplica a cualquier usuario en ese grupo. SID del grupo Administradores se almacena en el System.MDA cuando se crea una base de datos. Como resultado, el grupo de administradores siempre tendrá permiso para cambiar permisos en todos los objetos en esa base de datos. Este permiso no se puede tomar inmediatamente por cualquiera. Este permiso permanece incluso cuando todos los permisos se han revocado desde el grupo de administradores, y no se muestra en el cuadro de diálogo permisos. Ésta es otra razón para mantener una copia de seguridad y realizar un seguimiento de que System.MDA estaba en uso cuando se creó la base de datos.

Con la opción OwnerAccess en una consulta SQL


Un último punto de posibles confusiones manipula el uso de la siguiente frase en una consulta SQL:
   ... With OwnerAccess Option
				

Por ejemplo, observe este código:
   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
				

Este código genera este error:
Id. de base de datos no válido.

Esto es porque OwnerAccess hace referencia al propietario de la base de datos. El propietario es el creador de la base de datos. En otras palabras, OwnerAccess hace referencia a y la contraseña de usuario combinación del propietario (SID único) que se almacena en la base de datos (BD1.MDB en este caso). Sin embargo, el código no contiene las dos instrucciones necesarias para que apunte al archivo System.MDA de una base de datos protegida. En realidad, en este caso, sólo la instrucción SetDefaultWorkspace es esencial si archivo .ini del archivo .exe compilado que contiene una sección [Options] válida, está en el directorio \Windows.

El código utiliza la puerta trasera. No proporcionó el SID del propietario al motor de base de datos único para el motor no conoce la combinación de nombre y la contraseña predeterminada (Administrador, "") del usuario es el propietario de base de datos. Incluso si resulta que el Administrador de usuarios es el propietario de base de datos, sin necesidad de leer el archivo System.MDA, el motor no puede comprobar este hecho, por lo que da el error.

Notas para usuarios de Microsoft Access versión 2.0

Mediante el recientemente publicado 2.0 Microsoft Jet o Visual Basic 3.0 nivel de compatibilidad, Visual Basic puede obtener acceso a las bases de datos de Microsoft Access versión 2.0. A continuación son algunas notas para ayudarle a convertir una base de datos segura versión 1.1 en formato de Microsoft Access versión 2.0.

Si una base de datos de versión 1.x está protegida, permanecerá seguro si abrirlo con Microsoft Access versión 1.x o 2.0. Sin embargo, Microsoft Access versión 2.0 no puede utilizarse para cambiar o agregar permisos de la base de datos, incluso por el administrador, hasta que la base de datos se convierte a la versión 2.0.

Cuando instala Microsoft Access versión 2.0, se crea su propio archivo de grupo de trabajo (System.MDA). Si Microsoft Access versión 2.0 está instalado en el mismo directorio como versión 1.x, el archivo System.MDA de versión 1.x será SYSTEM1X.MDA cambiado de nombre.

Para realizar cambios en la seguridad de base de datos convertida, deberá utilizar una versión 2.0 System.MDA que tiene idénticas grupos y usuarios (y PID idénticos) que el original System.MDA.

Nota: PID (Id. personal) en Microsoft Access versión 2.0 son el equivalente de NIP (números de identificador personal) en la versión 1.x

Para crear un grupo de trabajo seguro:
  1. Utilice la herramienta Administrador de grupo 2.0 para crear un nuevo grupo de trabajo. Se trata de un archivo de versión 2.0 System.MDA.
  2. Volver a crear todos los usuarios y grupos de cuentas mediante el mismo nombre y PID números utilizados en Microsoft Access versión 1.x.
Para convertir una seguridad 1.x base de datos en formato 2.0:

Nota: En un grupo de trabajo segura, sólo los usuarios con permisos de Modify Design a todos los objetos pueden convertir un formato de versión 1.x en formato de la versión 2.0. Además, debe asignar permisos Modify Design a la base de datos de 1.x versión de Microsoft Access versión 1.x con el grupo de trabajo de versión 1.x.
  1. Asegúrese de que nadie está utilizando la base de datos de versión 1.x.
  2. Inicie sesión en Microsoft Access 2.0 como un miembro del grupo Administradores que no es el usuario Admin.
  3. En el menú Archivo, elija el comando Convertir base de datos.
  4. Seleccione la base de datos 1.x versión que desea convertir. Se le pedirá el nombre de versión 2.0 de la base de datos.

    Nota: El comando Convertir base de datos forzará que elija un nombre nuevo para la base de datos. Esto le permite mantener una copia de seguridad de la base de datos versión 1.x, como una vez convertido una base de datos de la versión 1.x a 2.0 que no puede volver a convertir versión 1.x.
  5. Que los usuarios unirse al nuevo grupo de trabajo de versión 2.0 (System.MDA) mediante la herramienta Administrador de grupo.

    Nota: Se puede también ello modificar el archivo MSACC20.ini en el directorio Windows. En la sección [Options] del archivo, cambie la entrada SystemDB para que señale a la versión 2.0 System.MDA archivo. La sección [Options] del archivo será similar al ejemplo siguiente:
          [Options]
          SystemDB=<microsoft access path>\SYSTEM.MDA
    
    						

Puntos clave para recordar

  1. Sólo Microsoft Access puede crear y modificar el archivo System.MDA.
  2. El archivo System.MDA contiene el SID exclusivo utilizada en una base de datos con permisos para ordenar out who is que para que Microsoft Access motor para exigir los permisos. Se obtiene el SID proporcionando el motor de Microsoft Access con un usuario válido y la combinación de contraseña, desde que obtiene el SID único que el motor se almacena en memoria para reforzar la seguridad en una base de datos abierta.
  3. Tanto Microsoft Access y Visual Basic deben señalarse a la ubicación del archivo System.MDA para obtener acceso a bases de datos que tengan seguridad y permisos que implementa.
  4. Hay una puerta trasera disponible para el programa de aplicación de Visual Basic Si cambia la contraseña para el valor predeterminado el usuario en el grupo Administradores (denominado Administrador) no es de la predeterminada ninguno ("").
  5. Si la frase "Con opción OwnerAccess" se utiliza en la consulta SQL de un método CreateQueryDef, CreateDynaset o CreateSnapshot, debe existir un puntero al archivo System.MDA. Incluso si utiliza la puerta trasera (la combinación predeterminada de usuario y la contraseña de administrador y "") y no parecen necesite System.MDA, cuando se utiliza "Con opción OwnerAccess" en una consulta SQL, el motor debe ver el archivo System.MDA para que coincida con el SID del propietario (creador) de la base de datos para el usuario que inició sesión.
  6. Las combinaciones de usuario y contraseña de inicio de sesión válidas se almacenan en el archivo System.MDA pero los permisos se almacenan en la base de datos (.mdb archivo) propio. Una clave única (SID) se extrae el System.MDA utilizando un usuario válido y una combinación de contraseña, suministrado el motor de Microsoft Access por el cuadro de diálogo Inicio de sesión en Microsoft Access o por el código de Visual Basic.

Propiedades

Id. de artículo: 105990 - Última revisión: miércoles, 12 de febrero de 2014 - Versión: 2.0
La información de este artículo se refiere a:
  • Microsoft Visual Basic 3.0 Professional Edition
  • Microsoft Visual Basic 3.0 Professional Edition
Palabras clave: 
kbnosurvey kbarchive kbmt kbinfo KB105990 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 105990

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