No permitir más de un inicio de sesión por usuario

Hola Fanci:
Si, puedes usar la autenticacion de Windows en un grupo de trabajo, lo
que se requiere es que los usuarios esten autenticados en el Servidor. En
unico problema que podrias tener con este esquema es de licencias. En un
Servidor Windows 2000/03 pagas si los usuarios se conectan para
autenticarse, usar archivos, impresion, etc. en fin para usar los servicios
de Sistema Operativo. Si tienes una red que NO usa servidores de Windows,
pero quiere usar SQL, es posible lograrlo pagando licencias de servirdores
(W2K y SQL) y sin pagar licencias de usuarios (CAL) para el Sistema
Operativo solo para SQL. En este caso usar la seguridad integrada cuesta $$$
porque hay que pagar licencias CAL de Windows.
En cuanto a la forma de agregar la cuenta (no conozco tu experiencia en
Redes asi que empiezo de los fundamentos): En un dominio existe una BD
central de recursos/usuarios que reside en 1 o mas servidores (Controladores
de Dominio) y todas las computadoras que pertenecen al Dominio usan dicha
BD. Cuando tienes un Workgroup cada computadora tiene su propia BD de
seguridad independiente del resto. Por ende si quieres usar recursos de red
en un Workgroup debes agregar los usuarios en cada una de las computadoras
que ofrezcan recursos. En tu caso deberas en el Servidor donde esta el SQL
agregar los usuarios locales y luego el Servidor de SQL los debera ver sin
problemas.
.Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Franci escribio:

Hola Javier,

¿la autenticación de Windows la puedo realizar sobre un grupo de
trabajo de la red o necesito forzosamente crear un dominio? es que en
principio sería para un grupo de trabajo. Un equipo tiene el SQL
Server instalado y los demás se conectarían a él. ¿Puedo realizar
esto en un grupo de trabajo con autentificación de Windows? es que al
intentar añadir un inicio de sesión con autenticacion de Windows me
pide el dominio y nombre de cuenta y no consigo que me acepte una
cuenta de otra máquina

Gracias

_______
Franci



"Javier Loria" escribió en el mensaje
news:%

Hola Franci:
Si la aplicacion esta hecha en VB6, los usuarios son usuarios de
Windows, porque quieres usar la autenticacion de SQL?.
Lo pregunto porque MS "desrecomienda" el uso de la seguridad de
SQL. Por ejemplo los BOL dicen "La autenticación de SQL Server
se proporciona por motivos de compatibilidad con versiones
anteriores.". Adicionalmente tiene problemas conocidos, como que
en internet hay software para desencriptar y obtener las claves de
todos los usuarios, como que las claves pasan en texto legible por
la red, como que no es posible regular la cantidad de veces que un
usuario se autentica, como que no es posible regular el minimo del
password, o cada cuando debe cambiarse la clave, etc.
Mi experiencia es que la autenticacion de SQL, solo sirve para
dar un falso sentido de seguridad, porque pide usuario y clave. Si
eso es lo que quieres, puedes hace un formulario de login y cada 7/8
veces haces BIP y mandas un messagebox con "Clave Incorrecta", los
usuarios tranquilos y tu aplicacion segura :)

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Franci escribio:

Hola grupo,

estoy realizando una aplicación vb6 contra SQL Server 2000, la
aplicación es multiusuario. Utilizo autentificación de SQL Server.
Al arrancar la aplicación pregunto por el nombre de usuario y su
contraseña, que utilizo como inicio de sesión para acceder a la base
de datos que utilizo.

El problema es que un mismo usuario puede entrar con su inicio
de sesión a través de la aplicación en dos máquinas distintas
existentes en la red. ¿Hay alguna forma que SQL Server controle que
sólo se
pueda realizar un inicio de sesión para un usuario?

Gracias de antemano

Saludos

_______
Franci

Muchas gracias de antemano por la paciencia Javier, a ver si lo he entendido
bien:

yo tengo SQL Server 2000 instalado en un Windows XP Professional, en
este equipo tendría que crear todas las cuentas de usuarios (desde el panel
de control de windows) para los usuarios que quiero que se conecten a la
base de datos que está en este equipo. Entonces podría crear sin problemas
los inicios de sesión desde SQL Server para esas cuentas creadas con
autenticación de windows, verdad?

Ahora bien, tendría que crear una cuenta de usuario de windows (desde el
panel de control de windows) en cada una de las máquinas de la red, con el
mismo usuario y password creados en la máquina servidor, ¿es esto así? ¿y
que pasa si un usuario cambia su password en la maquina remota y no en la
maquina servidor?

Saludos

_______
Franci


"Javier Loria" escribió en el mensaje
news:%

Hola Fanci:
Si, puedes usar la autenticacion de Windows en un grupo de trabajo,

lo

que se requiere es que los usuarios esten autenticados en el Servidor. En
unico problema que podrias tener con este esquema es de licencias. En un
Servidor Windows 2000/03 pagas si los usuarios se conectan para
autenticarse, usar archivos, impresion, etc. en fin para usar los

servicios

de Sistema Operativo. Si tienes una red que NO usa servidores de Windows,
pero quiere usar SQL, es posible lograrlo pagando licencias de servirdores
(W2K y SQL) y sin pagar licencias de usuarios (CAL) para el Sistema
Operativo solo para SQL. En este caso usar la seguridad integrada cuesta

$$$

porque hay que pagar licencias CAL de Windows.
En cuanto a la forma de agregar la cuenta (no conozco tu experiencia

en

Redes asi que empiezo de los fundamentos): En un dominio existe una BD
central de recursos/usuarios que reside en 1 o mas servidores

(Controladores

de Dominio) y todas las computadoras que pertenecen al Dominio usan dicha
BD. Cuando tienes un Workgroup cada computadora tiene su propia BD de
seguridad independiente del resto. Por ende si quieres usar recursos de

red

en un Workgroup debes agregar los usuarios en cada una de las computadoras
que ofrezcan recursos. En tu caso deberas en el Servidor donde esta el SQL
agregar los usuarios locales y luego el Servidor de SQL los debera ver sin
problemas.
.Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Franci escribio:
> Hola Javier,
>
> ¿la autenticación de Windows la puedo realizar sobre un grupo de
> trabajo de la red o necesito forzosamente crear un dominio? es que en
> principio sería para un grupo de trabajo. Un equipo tiene el SQL
> Server instalado y los demás se conectarían a él. ¿Puedo realizar
> esto en un grupo de trabajo con autentificación de Windows? es que al
> intentar añadir un inicio de sesión con autenticacion de Windows me
> pide el dominio y nombre de cuenta y no consigo que me acepte una
> cuenta de otra máquina
>
> Gracias
>
> _______
> Franci
>
>
>
> "Javier Loria" escribió en el mensaje
> news:%
>> Hola Franci:
>> Si la aplicacion esta hecha en VB6, los usuarios son usuarios de
>> Windows, porque quieres usar la autenticacion de SQL?.
>> Lo pregunto porque MS "desrecomienda" el uso de la seguridad de
>> SQL. Por ejemplo los BOL dicen "La autenticación de SQL Server
>> se proporciona por motivos de compatibilidad con versiones
>> anteriores.". Adicionalmente tiene problemas conocidos, como que
>> en internet hay software para desencriptar y obtener las claves de
>> todos los usuarios, como que las claves pasan en texto legible por
>> la red, como que no es posible regular la cantidad de veces que un
>> usuario se autentica, como que no es posible regular el minimo del
>> password, o cada cuando debe cambiarse la clave, etc.
>> Mi experiencia es que la autenticacion de SQL, solo sirve para
>> dar un falso sentido de seguridad, porque pide usuario y clave. Si
>> eso es lo que quieres, puedes hace un formulario de login y cada 7/8
>> veces haces BIP y mandas un messagebox con "Clave Incorrecta", los
>> usuarios tranquilos y tu aplicacion segura :)
>>
>> Saludos,
>>
>>
>> Javier Loria
>> Costa Rica
>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>> que pueda ser copiado y pegado al Query Analizer.
>> La version de SQL y Service Pack tambien ayuda.
>> Franci escribio:
>>> Hola grupo,
>>>
>>> estoy realizando una aplicación vb6 contra SQL Server 2000, la
>>> aplicación es multiusuario. Utilizo autentificación de SQL Server.
>>> Al arrancar la aplicación pregunto por el nombre de usuario y su
>>> contraseña, que utilizo como inicio de sesión para acceder a la base
>>> de datos que utilizo.
>>>
>>> El problema es que un mismo usuario puede entrar con su inicio
>>> de sesión a través de la aplicación en dos máquinas distintas
>>> existentes en la red. ¿Hay alguna forma que SQL Server controle que
>>> sólo se
>>> pueda realizar un inicio de sesión para un usuario?
>>>
>>> Gracias de antemano
>>>
>>> Saludos
>>>
>>> _______
>>> Franci

Hola Franci:
Con gusto.
a) Efectivamente deberas crear los usuarios en Windows XP Pro, que tiene
el "servidor" de SQL.
b) Es correcto, en las estaciones los clientes (no tienen que ser el
mismo usuario o password) deben conocer el usuario y Password que agregaste
en el Windows XP Pro.
c) ¿y que pasa si un usuario cambia su password en la maquina remota y
no en la maquina servidor?.
En el caso de XP, no hay problema porque te guarda las claves de
diferentes servidores (es un checkbox cuando uno se autentica) pero en
Windows2000/NT/9X si tienes el mismo usuario y clave y cambias la clave
local y no la remota se descompone la cosa. Esto es por la naturaleza del
Workgroup, si te sirve de consuelo igualmente se descompondran el sistema de
Archivos, de Impresion, etc. Cuando tienes un Grupo de Trabajo y compartes
recursos en cada maquina se guarda el usuario y la claves, el Windows XP es
lo sufientemente "habil" como para guardar las cuentas/claves de otros
servidores (si el usuario lo escoge), pero los otros Sistemas Operativos no.
Evalua la diferencia entre la seguridad de Windows y la de SQL. Yo no
creo que la de Windows sea perfecta, pero esta a anos luz de la de SQL. Si
me permites extenderme te doy algunos casos practicos:
a) El usuario A llama al usuario B por telefono para que le de la clave
porque solo B tiene permisos de hacer X. Crees que B viene el Lunes a
primera hora a cambiar su clave?. Si lo haciera donde lo hace? en el
Enterprise Manager, en Query Analizer o desde tu aplicacion?.
Si usas seguridad de SQL tendras que escribir las pantallas de cambio de
clave, crear tablas para el control de fechas de vencimiento de password y
procedimientos personalizados para el cambio de clave, etc.
b) Una vez que escribies el codigo para forzar el cambio periodico de
claves a los usuarios les toma 30 segundos aprender que pueden cambiar la
clave y luego volverla a cambiar otra vez al original para "saltarse" el
procedimiento. Por ende debes ahora guardar claves por cierta cantidad de
tiempo para fozar la seguridad, el problema es como guardas las claves?
Tienes que encriptarlas porque sino el DBA puede averiguar la clave de todos
los usuarios, tendras que aprender CRYPTOAPI para encriptar las claves, y te
digo no es bonito.
c) A los usuarios les gusta usar claves pequenas, algo simple de
preferencia solo [Enter] o alguna letra A-Z sin caracteres raros. El
problema de esto es que una maquina actualmente tarda unos segundos en
probar 1000 claves diferentes. Si usas la seguridad de SQL revisa la linea
1.
d) Los clientes ultimamente tienen la mania de conectarse a Internet, en
el momento en que lo hacen los desarrolladores debemos dejar de asumir un
"supuesto", y es nuestros usuarios son Ignorantes. Debe haber varios miles
de personas que saben como llegar a tu servidor y monitorear lo que trasmite
por la red, averiguando las claves que transmite. De hecho es una practica
recomendada de "hackers", ya que la mayoria de los usuarios "reutilizamos"
las claves, es facil una vez que tienes una clave encontrar el resto de
claves del usuario. Asi que encontrando la clave para la BD de SQL es
posible facilitarse el trabajo para encontrar la clave para el "WebBanking".
Si usas seguridad de SQL y deseas protegerte debes usar IPSEC o
certificados digitales o algun otro medio de encriptar, claro que eso
significara una importante carga adicional de procesador del Servidor y de
la Estacion.
Con tu requerimiento de no permitir que un usuario haga login en dos
máquinas distintas existentes en la red, descubriste solo la punta del
Iceberg, el codigo que Accotto te soluciona esta punta, pero no el resto, y
desgraciadamente el resto es 10 veces mas grande de lo que vez.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Franci escribio:

Muchas gracias de antemano por la paciencia Javier, a ver si lo he
entendido bien:

yo tengo SQL Server 2000 instalado en un Windows XP Professional,
en este equipo tendría que crear todas las cuentas de usuarios (desde
el panel de control de windows) para los usuarios que quiero que se
conecten a la base de datos que está en este equipo. Entonces podría
crear sin problemas los inicios de sesión desde SQL Server para esas
cuentas creadas con autenticación de windows, verdad?

Ahora bien, tendría que crear una cuenta de usuario de windows
(desde el panel de control de windows) en cada una de las máquinas de
la red, con el mismo usuario y password creados en la máquina
servidor, ¿es esto así? ¿y que pasa si un usuario cambia su password
en la maquina remota y no en la maquina servidor?

Saludos

_______
Franci


"Javier Loria" escribió en el mensaje
news:%

Hola Fanci:
Si, puedes usar la autenticacion de Windows en un grupo de
trabajo, lo que se requiere es que los usuarios esten autenticados
en el Servidor. En unico problema que podrias tener con este esquema
es de licencias. En un Servidor Windows 2000/03 pagas si los
usuarios se conectan para autenticarse, usar archivos, impresion,
etc. en fin para usar los servicios de Sistema Operativo. Si tienes
una red que NO usa servidores de Windows, pero quiere usar SQL, es
posible lograrlo pagando licencias de servirdores (W2K y SQL) y sin
pagar licencias de usuarios (CAL) para el Sistema Operativo solo
para SQL. En este caso usar la seguridad integrada cuesta $$$ porque
hay que pagar licencias CAL de Windows. En cuanto a la forma de
agregar la cuenta (no conozco tu experiencia en Redes asi que
empiezo de los fundamentos): En un dominio existe una BD central de
recursos/usuarios que reside en 1 o mas servidores (Controladores de
Dominio) y todas las computadoras que pertenecen al Dominio usan
dicha BD. Cuando tienes un Workgroup cada computadora tiene su
propia BD de seguridad independiente del resto. Por ende si quieres
usar recursos de red en un Workgroup debes agregar los usuarios en
cada una de las computadoras que ofrezcan recursos. En tu caso
deberas en el Servidor donde esta el SQL agregar los usuarios
locales y luego el Servidor de SQL los debera ver sin problemas.
.Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Franci escribio:

Hola Javier,

¿la autenticación de Windows la puedo realizar sobre un grupo de
trabajo de la red o necesito forzosamente crear un dominio? es que
en principio sería para un grupo de trabajo. Un equipo tiene el SQL
Server instalado y los demás se conectarían a él. ¿Puedo realizar
esto en un grupo de trabajo con autentificación de Windows? es que
al intentar añadir un inicio de sesión con autenticacion de Windows
me pide el dominio y nombre de cuenta y no consigo que me acepte una
cuenta de otra máquina

Gracias

_______
Franci



"Javier Loria" escribió en el mensaje
news:%

Hola Franci:
Si la aplicacion esta hecha en VB6, los usuarios son usuarios
de Windows, porque quieres usar la autenticacion de SQL?.
Lo pregunto porque MS "desrecomienda" el uso de la seguridad de
SQL. Por ejemplo los BOL dicen "La autenticación de SQL Server
se proporciona por motivos de compatibilidad con versiones
anteriores.". Adicionalmente tiene problemas conocidos, como
que en internet hay software para desencriptar y obtener las
claves de todos los usuarios, como que las claves pasan en texto
legible por
la red, como que no es posible regular la cantidad de veces que un
usuario se autentica, como que no es posible regular el minimo del
password, o cada cuando debe cambiarse la clave, etc.
Mi experiencia es que la autenticacion de SQL, solo sirve para
dar un falso sentido de seguridad, porque pide usuario y clave. Si
eso es lo que quieres, puedes hace un formulario de login y cada
7/8 veces haces BIP y mandas un messagebox con "Clave Incorrecta",
los usuarios tranquilos y tu aplicacion segura :)

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Franci escribio:

Hola grupo,

estoy realizando una aplicación vb6 contra SQL Server 2000, la
aplicación es multiusuario. Utilizo autentificación de SQL Server.
Al arrancar la aplicación pregunto por el nombre de usuario y su
contraseña, que utilizo como inicio de sesión para acceder a la
base de datos que utilizo.

El problema es que un mismo usuario puede entrar con su inicio
de sesión a través de la aplicación en dos máquinas distintas
existentes en la red. ¿Hay alguna forma que SQL Server controle
que sólo se
pueda realizar un inicio de sesión para un usuario?

Gracias de antemano

Saludos

_______
Franci

no lo entiendo, entonces desde una estación cliente como le indico con qué
inicio de sesión me conecto si el usario no es el mismo? yo con
autenticacion SQL Server en código vb hacía así:

'Realizamos la conexión a la base de datos
cn.ConnectionTimeout = 25 'Esperaremos hasta 25 segundos para realizar
la conexión
cn.Provider = "sqloledb" 'Establecemos el proveedor para la conexión
cn.Properties("Data Source").Value = cboServidor.Value
cn.Properties("Initial Catalog").Value = config.BaseDatos
cn.Properties("User ID").Value = txtUsuario.Text
cn.Properties("Password").Value = txtClave.Text

¿Puedes darme un ejemplo? Te estaría muy agradecido

Saludos

_______
Franci

"Javier Loria" escribió en el mensaje
news:

Hola Franci:
Con gusto.
a) Efectivamente deberas crear los usuarios en Windows XP Pro, que

tiene

el "servidor" de SQL.
b) Es correcto, en las estaciones los clientes (no tienen que ser el
mismo usuario o password) deben conocer el usuario y Password que

agregaste

en el Windows XP Pro.
c) ¿y que pasa si un usuario cambia su password en la maquina remota

y

no en la maquina servidor?.
En el caso de XP, no hay problema porque te guarda las claves de
diferentes servidores (es un checkbox cuando uno se autentica) pero en
Windows2000/NT/9X si tienes el mismo usuario y clave y cambias la clave
local y no la remota se descompone la cosa. Esto es por la naturaleza del
Workgroup, si te sirve de consuelo igualmente se descompondran el sistema

de

Archivos, de Impresion, etc. Cuando tienes un Grupo de Trabajo y compartes
recursos en cada maquina se guarda el usuario y la claves, el Windows XP

es

lo sufientemente "habil" como para guardar las cuentas/claves de otros
servidores (si el usuario lo escoge), pero los otros Sistemas Operativos

no.

Evalua la diferencia entre la seguridad de Windows y la de SQL. Yo no
creo que la de Windows sea perfecta, pero esta a anos luz de la de SQL. Si
me permites extenderme te doy algunos casos practicos:
> a) El usuario A llama al usuario B por telefono para que le de la

clave

porque solo B tiene permisos de hacer X. Crees que B viene el Lunes a
primera hora a cambiar su clave?. Si lo haciera donde lo hace? en el
Enterprise Manager, en Query Analizer o desde tu aplicacion?.
Si usas seguridad de SQL tendras que escribir las pantallas de cambio

de

clave, crear tablas para el control de fechas de vencimiento de password y
procedimientos personalizados para el cambio de clave, etc.
b) Una vez que escribies el codigo para forzar el cambio periodico de
claves a los usuarios les toma 30 segundos aprender que pueden cambiar la
clave y luego volverla a cambiar otra vez al original para "saltarse" el
procedimiento. Por ende debes ahora guardar claves por cierta cantidad de
tiempo para fozar la seguridad, el problema es como guardas las claves?
Tienes que encriptarlas porque sino el DBA puede averiguar la clave de

todos

los usuarios, tendras que aprender CRYPTOAPI para encriptar las claves, y

te

digo no es bonito.
c) A los usuarios les gusta usar claves pequenas, algo simple de
preferencia solo [Enter] o alguna letra A-Z sin caracteres raros. El
problema de esto es que una maquina actualmente tarda unos segundos en
probar 1000 claves diferentes. Si usas la seguridad de SQL revisa la linea
1.
d) Los clientes ultimamente tienen la mania de conectarse a Internet,

en

el momento en que lo hacen los desarrolladores debemos dejar de asumir un
"supuesto", y es nuestros usuarios son Ignorantes. Debe haber varios miles
de personas que saben como llegar a tu servidor y monitorear lo que

trasmite

por la red, averiguando las claves que transmite. De hecho es una practica
recomendada de "hackers", ya que la mayoria de los usuarios "reutilizamos"
las claves, es facil una vez que tienes una clave encontrar el resto de
claves del usuario. Asi que encontrando la clave para la BD de SQL es
posible facilitarse el trabajo para encontrar la clave para el

"WebBanking".

Si usas seguridad de SQL y deseas protegerte debes usar IPSEC o
certificados digitales o algun otro medio de encriptar, claro que eso
significara una importante carga adicional de procesador del Servidor y de
la Estacion.
> Con tu requerimiento de no permitir que un usuario haga login en dos
máquinas distintas existentes en la red, descubriste solo la punta del
Iceberg, el codigo que Accotto te soluciona esta punta, pero no el resto,

y

desgraciadamente el resto es 10 veces mas grande de lo que vez.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Franci escribio:
> Muchas gracias de antemano por la paciencia Javier, a ver si lo he
> entendido bien:
>
> yo tengo SQL Server 2000 instalado en un Windows XP Professional,
> en este equipo tendría que crear todas las cuentas de usuarios (desde
> el panel de control de windows) para los usuarios que quiero que se
> conecten a la base de datos que está en este equipo. Entonces podría
> crear sin problemas los inicios de sesión desde SQL Server para esas
> cuentas creadas con autenticación de windows, verdad?
>
> Ahora bien, tendría que crear una cuenta de usuario de windows
> (desde el panel de control de windows) en cada una de las máquinas de
> la red, con el mismo usuario y password creados en la máquina
> servidor, ¿es esto así? ¿y que pasa si un usuario cambia su password
> en la maquina remota y no en la maquina servidor?
>
> Saludos
>
> _______
> Franci
>
>
> "Javier Loria" escribió en el mensaje
> news:%
>> Hola Fanci:
>> Si, puedes usar la autenticacion de Windows en un grupo de
>> trabajo, lo que se requiere es que los usuarios esten autenticados
>> en el Servidor. En unico problema que podrias tener con este esquema
>> es de licencias. En un Servidor Windows 2000/03 pagas si los
>> usuarios se conectan para autenticarse, usar archivos, impresion,
>> etc. en fin para usar los servicios de Sistema Operativo. Si tienes
>> una red que NO usa servidores de Windows, pero quiere usar SQL, es
>> posible lograrlo pagando licencias de servirdores (W2K y SQL) y sin
>> pagar licencias de usuarios (CAL) para el Sistema Operativo solo
>> para SQL. En este caso usar la seguridad integrada cuesta $$$ porque
>> hay que pagar licencias CAL de Windows. En cuanto a la forma de
>> agregar la cuenta (no conozco tu experiencia en Redes asi que
>> empiezo de los fundamentos): En un dominio existe una BD central de
>> recursos/usuarios que reside en 1 o mas servidores (Controladores de
>> Dominio) y todas las computadoras que pertenecen al Dominio usan
>> dicha BD. Cuando tienes un Workgroup cada computadora tiene su
>> propia BD de seguridad independiente del resto. Por ende si quieres
>> usar recursos de red en un Workgroup debes agregar los usuarios en
>> cada una de las computadoras que ofrezcan recursos. En tu caso
>> deberas en el Servidor donde esta el SQL agregar los usuarios
>> locales y luego el Servidor de SQL los debera ver sin problemas.
>> .Saludos,
>>
>>
>> Javier Loria
>> Costa Rica
>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>> que pueda ser copiado y pegado al Query Analizer.
>> La version de SQL y Service Pack tambien ayuda.
>>
>> Franci escribio:
>>> Hola Javier,
>>>
>>> ¿la autenticación de Windows la puedo realizar sobre un grupo de
>>> trabajo de la red o necesito forzosamente crear un dominio? es que
>>> en principio sería para un grupo de trabajo. Un equipo tiene el SQL
>>> Server instalado y los demás se conectarían a él. ¿Puedo realizar
>>> esto en un grupo de trabajo con autentificación de Windows? es que
>>> al intentar añadir un inicio de sesión con autenticacion de Windows
>>> me pide el dominio y nombre de cuenta y no consigo que me acepte una
>>> cuenta de otra máquina
>>>
>>> Gracias
>>>
>>> _______
>>> Franci
>>>
>>>
>>>
>>> "Javier Loria" escribió en el mensaje
>>> news:%
>>>> Hola Franci:
>>>> Si la aplicacion esta hecha en VB6, los usuarios son usuarios
>>>> de Windows, porque quieres usar la autenticacion de SQL?.
>>>> Lo pregunto porque MS "desrecomienda" el uso de la seguridad de
>>>> SQL. Por ejemplo los BOL dicen "La autenticación de SQL Server
>>>> se proporciona por motivos de compatibilidad con versiones
>>>> anteriores.". Adicionalmente tiene problemas conocidos, como
>>>> que en internet hay software para desencriptar y obtener las
>>>> claves de todos los usuarios, como que las claves pasan en texto
>>>> legible por
>>>> la red, como que no es posible regular la cantidad de veces que un
>>>> usuario se autentica, como que no es posible regular el minimo del
>>>> password, o cada cuando debe cambiarse la clave, etc.
>>>> Mi experiencia es que la autenticacion de SQL, solo sirve para
>>>> dar un falso sentido de seguridad, porque pide usuario y clave. Si
>>>> eso es lo que quieres, puedes hace un formulario de login y cada
>>>> 7/8 veces haces BIP y mandas un messagebox con "Clave Incorrecta",
>>>> los usuarios tranquilos y tu aplicacion segura :)
>>>>
>>>> Saludos,
>>>>
>>>>
>>>> Javier Loria
>>>> Costa Rica
>>>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>>>> que pueda ser copiado y pegado al Query Analizer.
>>>> La version de SQL y Service Pack tambien ayuda.
>>>> Franci escribio:
>>>>> Hola grupo,
>>>>>
>>>>> estoy realizando una aplicación vb6 contra SQL Server 2000, la
>>>>> aplicación es multiusuario. Utilizo autentificación de SQL Server.
>>>>> Al arrancar la aplicación pregunto por el nombre de usuario y su
>>>>> contraseña, que utilizo como inicio de sesión para acceder a la
>>>>> base de datos que utilizo.
>>>>>
>>>>> El problema es que un mismo usuario puede entrar con su inicio
>>>>> de sesión a través de la aplicación en dos máquinas distintas
>>>>> existentes en la red. ¿Hay alguna forma que SQL Server controle
>>>>> que sólo se
>>>>> pueda realizar un inicio de sesión para un usuario?
>>>>>
>>>>> Gracias de antemano
>>>>>
>>>>> Saludos
>>>>>
>>>>> _______
>>>>> Franci

con el ej q te di da el nro de sesiones conectadas!! vos podrias hacer un
store q retorne ese numero y q tu aplicacion lo lea, si el numero es mayor q
cero marcaras un error.

Revisa igual lo q dice Javier de la seguridad Windows!! es muy importante lo
q el te plantea, no se tu caso en particular pero en el mio no puedo usar
ese tipo de seguridad por compatibilidad con otros SO y BDD, pero quizas tu
caso sea distinto.

Un saludo

Accotto Maximiliano Damian
Fundicion San Cayetano S.A.
Buenos Aires Argentina

Gerente de Sistemas y Tecnologia
()

"Franci" escribió en el mensaje
news:

Gracias Accotto,

pero no entiendo lo último, lo del if y el raiseerror, ¿esto donde lo
pondría?

Saludos

_______
Franci

"Accotto Maximiliano Damian" escribió
en el mensaje news:
> Hola Franci!!! aca te mando un ej de como lo podrias hacer.
>
> declare @contar int
>
> set @contar = (select count(*) from sysprocesses where loginame
='sysadm')
> select @contar
>
>
> El tema es asi: En la tabla sysprocesses estan los datos de todos los
> procesos ahi yo cuento si el usuario (sysadm) cuantos tiene (si tiene

mas

q
> 0 es porque esta logeado)
>
> y lo muestro en la varible @contar
>
> luego con esa varible podrias hacer un if y raiseerror por ej.
>
> Espero haber sido de utilidad.
>
> Un saludo
>
> Accotto Maximiliano Damian
> Fundicion San Cayetano S.A.
> Buenos Aires Argentina
>
> Gerente de Sistemas y Tecnologia
> ()
>
> "Franci" escribió en el mensaje
> news:
> > Hola grupo,
> >
> > estoy realizando una aplicación vb6 contra SQL Server 2000, la
> > aplicación es multiusuario. Utilizo autentificación de SQL Server. Al
> > arrancar la aplicación pregunto por el nombre de usuario y su
contraseña,
> > que utilizo como inicio de sesión para acceder a la base de datos que
> > utilizo.
> >
> > El problema es que un mismo usuario puede entrar con su inicio de
> sesión
> > a través de la aplicación en dos máquinas distintas existentes en la
red.
> > ¿Hay alguna forma que SQL Server controle que sólo se pueda realizar

un

> > inicio de sesión para un usuario?
> >
> > Gracias de antemano
> >
> > Saludos
> >
> > _______
> > Franci
> >
> >
>
>