GRUPOS DE TRABAJO
avergara
Alguien sabe si es posible crear un grupo de trabajo sin administrador??
Gracias
--
Ana María Vergara
SoftJaén
> Alguien sabe si es posible crear un grupo de trabajo
> sin administrador??
Hola, Ana María:
Si por «administrador» entendemos la cuenta genérica del usuario «Admin»,
que yo sepa, no es posible crear un archivo de información de grupos de
trabajo sin que figure tal cuenta; es más, ni se puede eliminar.
Pero el hecho que exista, no significa que dicha cuenta haga lo que le venga
en gana. Si vas a utilizar la seguridad a nivel de usuario, lo recomendable
es que la cuenta del usuario «Admin» no disponga de ningún permiso sobre la
base de datos, a la cual se encuentra asociada el archivo de información de
grupos de trabajo. Antes de quitarle los permisos al usuario «Admin»,
deberás de crear otra cuenta y asignarle los permisos administrativos
correspondientes.
Un saludo
--
Enrique Martínez
[MS MVP - VB]
Nota informativa: La información contenida en este mensaje, así como el
código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin
garantías de ninguna clase, y no otorga derecho alguno. Usted asume
cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o
sugerido en el presente mensaje.
Eduardo S.
para generar usuarios y permisos automáticamente al usuario "Admin" lo quita
del grupo "Administradores" pero queda en el Grupo "Usuarios".
Por Default cuando se accesa a un archivo MDB se hace a traves del usuario
"ADMIN" y a menos que tenga asociado un password access entra con este
usuario sin preguntar ni usuario ni password.
Ten cuidado de los permisos asociados al grupo usuarios pues cualquier
persona tendrá derecho a esos permisos. Yo acostumbro asignar a este grupo
los permisos de los usuarios y así evito tenerles que dar contraseña, líos
con el archivo system.mdw y a la vez que modifiquen o utilicen recusros de la
base.
Chea
de Marius y de Andrew Wrigley (este último a su vez cita un libro de Garry
Robinson en inglés).
La idea es que el grupo de trabajo mdw no se distribuye con la aplicación,
con lo que es imposible obtener contraseñas, sino que usuarios y permisos se
crean en tiempo de ejecución.
Marius explicó detalladamente todo el proceso, pero ahora no encuentro más
que un hilo con un enlace a la web del Búho que ya no está "on line" y que
tendrás que descargarte.
Busca con Google en este mismo foro Marius seguridad o Andrew seguridad y
encontrarás más información.
--
Saludos
José Bengoechea Ibaceta [MS-MVP Access]
http://jbengoechea.com/
"avergara" <aver...@discussions.microsoft.com> escribió en el mensaje
news:670A3C6F-4D3A-4E63...@microsoft.com...
SoftJaén
>
> La idea es que el grupo de trabajo mdw no se distribuye con la aplicación,
> con lo que es imposible obtener contraseñas, sino que usuarios y permisos
> se crean en tiempo de ejecución.
Hola, José:
¿He leído bien? ¿Que no se distribuya el archivo de información de grupos de
trabajo, junto con la base de datos de Access? Si es así, ¿cómo se abre una
base de datos, cuyo propietario es una cuenta de usuario distinta del
usuario genérico «Admin»?
Si yo creo una base de datos nueva, con una cuenta de usuario distinta del
usuario «Admin», y tanto a ésta cuenta, como a la de los grupos genéricos
«Admins» y «Users», les quito todos los permisos sobre la propia base de
datos, como sobre los restantes objetos existentes, ¿cómo se abre la base de
datos, si no existe el archivo de información de grupos de trabajo?
Para un ejemplo, soy capaz de adjuntar una base de datos nueva, sin
contraseña alguna, y completamente vacía. El que la abra, le invito a un
café. Y si alguien la puede abrir, y es capaz de crear una sola tabla, le
invito a una copa y puro. :-)
Chea
Pero no me pidas que te lo explique detalladamente porque de memoria no
sabría y el enlace de Marius explicando todo el funcionamiento se ha quedado
en el foro "off line" del Búho. Tendrás que bajártelo.
La idea, era que al abrir la BD, mediante código creas un nuevo Workspace y
"recreas" los usuarios con su PID y contraseña, que naturalmente te sabes
porque los has puesto tú. Es bastante elaborado, pero no es que se pueda
hacer, es que está hecho.
Sobre esta idea de no distribuir el mdw yo he hecho una cosa bastante más
sencilla para proteger una sola tabla: Quito los permisos para esa tabla y
la sustituyo por una consulta WITH OWNER ACCESS OPTION. Claro que entonces
tengo que proteger la consulta ocultándola y evitando que se salten el
inicio.
--
Saludos
José Bengoechea Ibaceta [MS-MVP Access]
http://jbengoechea.com/
"SoftJaén" <grupo_n...@softjaen.es> escribió en el mensaje
news:ukPNaXYY...@TK2MSFTNGP02.phx.gbl...
José Mª Fueyo
No se sí te referirás a éste "peaso" hilo ¡33 post ni más ni menos!
http://tinyurl.com/glfw8
Salu2
--
José Mª Fueyo
[MS MVP Access]
avergara
intentare ver lo sugerido por Marius
--
Ana María Vergara
SoftJaén
> La idea, era que al abrir la BD, mediante código creas un nuevo Workspace
> y "recreas" los usuarios con su PID y contraseña, que naturalmente te
> sabes porque los has puesto tú. Es bastante elaborado, pero no es que se
> pueda hacer, es que está hecho.
>
Es que en eso mismo consiste la seguridad a nivel de usuario del motor
Microsoft Jet. La seguridad de la base de datos se debe definir desde el
primer momento en que se crea la base de datos y se diseñan sus objetos,
pero nunca cuando la base de datos se encuentre terminada, que es cuando
suelen venir los problemas.
Todos sabemos que la seguridad de Access no es la de SQL Server, pero
sabiendo hacer las cosas bien, podemos asegurar la base de datos de una
manera fiable, asignando los permisos a aquellos usuarios y grupos que
creamos oportuno.
También dependerá el grado de seguridad que deseemos darle a nuestra base de
datos. Si es para un pequeño grupo de trabajo, de cuatro o cinco usuarios, y
los datos tampoco son una gran cosa, pues creo que no merece la pena aplicar
la seguridad a nivel de usuario. Quizás, con aplicar la seguridad a nivel
compartido, se podría proteger la base de datos de usuarios ajenos o no
deseados.
Aprovecho ésta conversación, para dejaros un extracto de un artículo que
llevo tiempo escribiendo sobre la seguridad del motor Microsoft Jet 4.0 (y
que no sé cuando leches lo voy a terminar), donde indico un esquema de
cuales serían los pasos que se podrían seguir, para activar la seguridad a
nivel de usuario.
Mayormente el artículo está enfocado para los programadores de bases de
datos Access, y no para usuarios de Microsoft Access, porque prácticamente
todo el artículo está lleno de ejemplos con código fuente de Visual Basic
.NET.
De camino que le echáis un vistazo, y si puede ser, os agradecería
enormemente que me comentéis si hay algo mal, o que se eche en falta. :-)
Cómo activar la seguridad a nivel de usuario
=================================
1. Crear un nuevo archivo de información de grupos de trabajo.
2. Establecer una contraseña para el usuario genérico Admin.
3. Crear un nuevo usuario y agregarlo al grupo Admins.
Una vez activada la seguridad a nivel de usuario, protegeríamos nuestro
archivo de información, aún más si cabe, de la siguiente manera:
4. Abrir una sesión con la cuenta del usuario creado recientemente.
5. Quitar al usuario Admin del grupo Admins, por lo que dicho grupo sólo se
quedará con el usuario creado al efecto, ya que necesariamente tiene que
existir una cuenta de usuario en el grupo Admins. Igualmente, si no desea
permitir que el usuario Admin adscrito al archivo de información de grupos
de trabajo, pueda crear nuevas bases de datos, deberá de eliminar a dicho
usuario genérico del grupo Users. Tenga en cuenta que en ningún caso, se
pueden eliminar definitivamente la cuenta del usuario Admin o las cuentas de
grupos por defecto Admins y Users.
Nota: Si está utilizando la interfaz de usuario de Microsoft Access, no
será posible eliminar al usuario Admin, o a cualquier otro usuario que haya
creado, del grupo genérico Users. Para tal fin, deberá de ejecutar las
consultas necesarias del lenguaje SQL del motor Microsoft Jet 4.0, junto con
el proveedor Jet Ole Db.
6. Crear un nuevo grupo de trabajo (Admins2, por ejemplo) que será el único
grupo administrador que exista en el archivo de información de grupos de
trabajo.
Ahora, ya estaríamos en condiciones de asociar nuestra base de datos al
archivo de información de grupos de trabajo. Para ello, actuaríamos como
sigue:
7. Crear una nueva base de datos, cuyo propietario será el administrador
único existente.
8. Abrir una conexión con la base de datos recién creada, indicando la ruta
del archivo de información al cual queremos vincular la base de datos.
9. Asignar al grupo Admins2 todos los permisos sobre la propia base de
datos, así como para el contenedor Tables.
10. Añadir al grupo Admins2 al usuario propietario de la base de datos, que
será el que ejerza de administrador único de la base de datos. Por supuesto,
si desea tener varios administradores, con sólo añadir las cuentas de
usuarios a dicho grupo, es más que suficiente.
11. Revocar todos los privilegios que sobre la base de datos y restantes
tablas existentes, tengan los grupos por defecto Admins y Users, de ésta
manera, los usuarios que puedan estar adscritos a los mencionados grupos, no
podrán abrir la base de datos, ni podrán crear nuevas tablas.
12. Crear los restantes objetos (Tablas, Consultas) de la base de datos.
13. Crear nuevos grupos de trabajo y asignarles los correspondientes
permisos sobre la propia base de datos y restantes objetos que la conforman.
14. Añadir nuevas cuentas de usuarios.
15. Agregar las cuentas de usuarios a sus respectivos grupos, de esta forma
los usuarios heredarán implícitamente los permisos del grupo al que hayan
sido adscritos.
16. Si resultase necesario, configurar explícitamente los permisos en
particular para una determinada cuenta de grupo o usuario.
Lo dicho, si observáis que algo anda mal, no dudéis en comentármeto.
Chea
Parece claro, pero dices que los ejemplos están llenos de código ¿No es más
sencillos usar los asistentes de Access?
Por otro lado, habíamos quedado en que la seguridad basada en mdw es poco
fiable si distribuyes el propio mdw, y no parece que expongas una
alternativa. Si no se trata de guardar los secretos del CNI a mi me basta
con la protección "blanda" que dan los mdw, que además me ahorra programar
un sistema de usuarios y permisos porque es una utilidad que ya viene con
Access, pero en ocasiones hay información que sí es crítica y que debería
estar mejor protegida.
--
Saludos
José Bengoechea Ibaceta [MS-MVP Access]
http://jbengoechea.com/
"SoftJaén" <grupo_n...@softjaen.es> escribió en el mensaje
news:ujAmYwZY...@TK2MSFTNGP02.phx.gbl...
SoftJaén
>
> dices que los ejemplos están llenos de código ¿No es más sencillos usar
> los asistentes de Access?
Por supuesto que es más fácil utilizar los asistentes que nos ofrece la
interfaz de usuario de Microsoft Access. Pero amigo, recuerda que yo soy
programador de Visual Basic, y ya comenté, que el artículo va dirigido
principalmente a programadores que utilizan bases de datos Access en sus
programas, en éste caso, a través del motor Microsoft Jet en su versión 4.0,
por lo que intento mostrar una alternativa a los Asistentes, dado que se
supone, que el usuario final del programa, va a interactuar con mi
aplicación; es decir, que no va a utilizar Microsoft Access. Digamos que es
implementar la seguridad mediante código fuente, sin necesidad de Asistente
alguno. :-)
> Por otro lado, habíamos quedado en que la seguridad
> basada en mdw es poco fiable si distribuyes el propio mdw,
> y no parece que expongas una alternativa.
No. Yo al menos, no he dicho eso. La seguridad del motor Microsoft Jet no
está a la altura, ni mucho mechos, de un sistema cliente/servidor como
Microsoft SQL Server, o como el propio sistema operativo, si hablamos de
sistemas basados en NT. Pero tampoco es que no sirva para nada. Sabiendo
hacer las cosas bien, y aplicar la seguridad desde un primer momento, se
puede asegurar perfectamente una base de datos Microsoft Access, utilizando
un archivo de información de grupos de trabajo.
Pero, claro está. Tanto Microsoft Access como el motor Microsoft Jet (que
más o menos biene a ser lo mismo), están enfocados a ser un gestor de
archivos de base de datos, y como cualquier otro archivo que se encuentra en
una máquina, es vulnerable a cualquier tipo de ataque.
Como bien podrás comprender, una vez que yo le entrege la aplicación al
cliente, es su responsabilidad el permitir que en sus máquinas se instalen
cualquier programa que sirva para averiguar las contraseñas de los usuarios
incluidos en un archivo *.mdw. Yo, me puedo responsabilizar de mi
aplicación, y de los fallos que pueda tener, pero no me voy a
responsabilizar de los programas que instalen sus empleados. Yo puedo
indicarle a mi cliente, los inconvenientes que tiene la seguridad de Access,
y le podré poner el trabajo difícil a las personas que deseen romper la
seguridad de la base de datos, pero ahí termina mi trabajo. Si mi cliente
desea más seguridad, pues ya sabes a lo que toca: adquirir Microsoft SQL
Server, o instalar su versión "light", el MSDE. Pero si instala el motor de
SQL Server, lo mismo tiene que hacer una inversión en cambiar los equipos
informáticos. :-)
> Si no se trata de guardar los secretos del CNI a mi
> me basta con la protección "blanda" que dan los mdw, que además
> me ahorra programar un sistema de usuarios y permisos porque es
> una utilidad que ya viene con Access, pero en ocasiones hay
> información que sí es crítica y que debería estar mejor protegida.
Efectivamente. Para una pequeña empresa, que necesita una base de datos para
llevar la gestión del negocio, invertir en seguridad no creo que sea el tema
prioritario de la empresa, al menos, es mi opinión personal. El "chorizo"
que entre a robar a su negocio, va en busca de los dineros, y puede ser que
le guste el PC de la secretaria, y se lo lleve de camino, por lo que
entiendo que invertirá para evitar que no entren ladrones a su empresa. Si
el hombre es precavido, tendrá una copia de seguridad de los datos fuera de
su empresa, con lo que podrá restaurar los mismos, y quizás pierda algunos
datos, pero nada más. Ahora bien, si aparte de robarle el PC, no se ha
preocupado de hacer copias de seguridad, entonces ... ¡Apaga y vámonos! :-)