bueno amigo rdoggsv lo que se promete se cumple aqui te dejo la diferencia entre estos dos conceptos
Grupo de Trabajo
En un grupo de trabajo toda la seguridad se maneja localmente en cada equipo. Cada máquina tiene localmente su lista de usuarios autorizados con las contraseñas correspondientes. Es decir, tanto la autenticación como la autorización se ejecutan localmente en cada máquina.
Debemos tener en cuenta que el equipo en sí mismo también es un recurso de red. Cuando iniciamos sesión nos Autentica y nos Autoriza a utilizarlo. Luego cuando vamos a acceder a un recurso local, como ya estamos autenticados, solamente verifica si estamos autorizados para acceder al mencionado recurso.
En cambio cuando vamos a acceder a un recurso remoto, este equipo remoto debe previamente autenticarnos para poder evaluar si estamos autorizados a acceder al recurso compartido.
Las soluciones en un grupo de trabajo son dos: duplicar la cuenta de usuario en ambos equipos, o elegir conectarse como otro usuario, especificando un Usuario-Contraseña válidos en el equipo remoto. Es recomendable la segunda.
El esquema de grupo de trabajo tiene ventajas: no se necesitan “servers” que en general son mucho más caros y la administración es relativamente sencilla. Pero también surgen inconvenientes: cuando aumenta el número de equipos se incrementa la tarea de administración ya que cada cambio hay que efectuarlo en todos y cada uno de los equipos. Además no se puede manejar en forma centralizada, ya que por definición de grupo de trabajo cada equipo es “independiente”. Cuando aumenta el número de máquinas o cuando se requiere administración centralizada o cuando la seguridad pasa a ser un tema importante, la solución es un ambiente de dominio.
Dominio
En un ambiente de dominio, hay uno o más “servers” que cumplen la función de Controladores de Dominio, una de cuyas funciones principales es Autenticar.
Vamos a ver primero el proceso con clientes Windows NT, Windows 2000 y Windows XP, ya que con Windows 9x el proceso es distinto. Algo que habrán notado seguramente, es que con estos sistemas operativos como clientes, hay que crear una cuenta de máquina en el dominio, inclusive con los servidores miembros. El equipo tiene cuenta en el dominio, se autentica durante el proceso de inicio, a partir de lo cual se arma un canal seguro de comunicación que servirá para el transporte de las credenciales de autenticación de los usuarios que accedan a los recursos del mismo. Si observamos el tráfico de red generado en el arranque de una máquina, veremos que sucede un proceso de autenticación muy similar al de un usuario. En lenguaje humano diríamos que luego de la autenticación del equipo, sucede un diálogo similar a “¿Puedo enviar a autenticar usuarios del dominio?” seguido por “Si mandámelos a mí, que yo verifico autenticidad”
A partir de esto cuando un equipo necesita autenticar usuarios del dominio envía las credenciales suministradas por el usuario al controlador de dominio quien verifica la autenticidad de las mismas y devuelve una confirmación de la autenticación e información adicional tal como pertenencia a grupos del dominio y derechos específicos del dominio.
Cuando esta información es recibida por el cliente se construye localmente una credencial de autenticación (Access Token) donde consta quién es, a qué grupos pertenece y los derechos que tiene. Esta credencial es usada localmente para el proceso de Autorización previo al acceso a recursos.
Cuando este usuario que ya inició sesión (ya fue autorizado al inicio de sesión interactivo local) se va a conectar a un recurso remoto tiene que probar su identidad. Dependiendo del tipo de autenticación que se utilice (NTLM o Kerberos) este proceso es diferente.
Si se está usando un dominio NT4, el cliente reenvía las credenciales del usuario (Usuario-Contraseña) al server remoto, quien repite el proceso de Autenticación ante el controlador de dominio seguido de la Autorización local. Bien, a decir verdad, no se envía la contraseña sino que se produce un mecanismo llamado Challenge-Response donde se prueba que conoce la contraseña sin necesidad de enviarla. Hay que recalcar que el server remoto es quien con la información enviada desde el cliente, contacta al controlador de dominio para que haga la autenticación, a partir de lo cual el propio server autoriza o no la conexión. Este proceso de autenticación se produce una sola vez por cada server, no importando a cuántos recursos del mismo se conecte el usuario, y dura hasta terminar la sesión (aprox. 15 minutos después de desconectarse o inmediatamente forzando desde el server). Es decir hay una sola sesión entre un determinado cliente y un server, no se puede conectar a un server en forma simultánea con dos cuentas diferentes.
En caso de dominio Windows 2000, el método de autenticación es Kerberos y la diferencia fundamental es que es el propio cliente quien recurre al servicio de Kerberos para obtener una pieza de información (Ticket) que será presentada al server remoto. Con esta información (Ticket) el server puede verificar la autenticidad del usuario sin contactar a un controlador de dominio. Vale lo mismo que en el caso anterior: no se puede tener simultáneamente dos sesiones con diferente usuario entre los mismos cliente-server.
Si los clientes son Windows 9x o Windows ME, no tienen cuenta de máquina en el dominio. El tema es que estos sistemas operativos no manejan autenticación a nivel de usuario, por lo que lo único que se les configura es a quién le envían la información para que haga la autenticación; esto puede ser a un dominio o simplemente a otro equipo que pueda autenticar usuarios (Windows 2000 Professional por ejemplo). Localmente no existe, salvo una excepción, el proceso de autorización ya que estando los recursos locales sobre FAT no se maneja seguridad a nivel de usuario. La excepción es si hay carpetas o impresoras compartidas que fueron configuradas con seguridad a nivel de usuario. Vale siempre lo mismo que en los casos anteriores: no se puede tener simultáneamente dos sesiones con diferente usuario entre los mismos cliente-server.
Resumiendo
En un grupo de trabajo la autenticación y autorización se produce y se administra localmente en cada equipo. En un ambiente de domino, la autenticación la hace un controlador de dominio, en el server que tiene el recurso se produce sólo la autorización.
Muchas veces he visto en foros y listas preguntas que no aclaran si están en dominio o grupo de trabajo, que no especifican el tipo de dominio (NT4 o W2k), o ni siquiera el tipo de cliente. Esto hace que sea imposible responder muchas de las preguntas. O inclusive es común ver errores conceptuales importantes como que estando en un ambiente de dominio se habla de “el logon al server…” ¿a qué llama logon? ¿autenticación o autorización? ¿pide o rechaza Usuario-Contraseña? ¿niega el acceso?
Es importante tener en cuenta que aunque puedo haber iniciado sesión en un equipo con un usuario, puedo tener varias conexiones simultáneas con diferentes equipos remotos, usando una cuenta de usuario diferente para cada uno de ellos. Lo que no se puede hacer es dos sesiones simultáneas con el mismo equipo y distinta cuenta, o lo que algunos han querido hacer que es iniciar sesión simultáneamente en dos dominios diferentes
