WindowServer

La propuesta de esta nota es aclarar conceptos tan importantes como son: autenticación y autorización, las diferencias entre grupos de trabajo y dominio, que no son claras para todos, y cómo se producen los procesos de autenticación y autorización, en cada caso y para los diferentes tipos de dominio y clientes

Conceptos: Autenticación y Autorización

La diferencia entre estos dos conceptos es muy importante para tener en claro tanto desde el punto de vista seguridad, como para resolución de problemas y administración de la red.

Cuando iniciamos sesión en un equipo que forma parte de una red normalmente se ejecutan estos dos procesos en forma sucesiva y automáticamente previo a que veamos la familiar apariencia de nuestro escritorio de Windows. Lo mismo ocurre cuando vamos a acceder a un recurso compartido de red. El hecho que se ejecuten en forma automática y sucesivamente hace que pensemos que en realidad se trata de un solo proceso, pero en realidad son dos procesos sumamente diferentes.

La autenticación es el proceso con el que demostramos ser quienes decimos. Eso es, decimos ser determinado Usuario y lo demostramos introduciendo la contraseña del mismo. El sistema verificará que la contraseña sea la correcta, lo cual le probará que somos quien decimos ser pues “conocemos el secreto”

La mayoría de los sistemas de autenticación están basados en la técnica conocida como “Secreto Compartido” y se explica de la siguiente forma: si sólo dos conocemos un secreto y yo soy uno, el que me demuestre que conoce el secreto tiene que ser el otro”. Llevado a términos de inicio de sesión: Si el Controlador de Dominio conoce la contraseña del usuario “Usuario1”, quien diga ser “Usuario1” y demuestre conocer la contraseña correspondiente, debe ser el usuario “Usuario1”.

Mediante esta técnica se produce el proceso de Autenticación, la verificación de identidad, que no es lo mismo que la autorización para acceder a un recurso. Debemos tener en cuenta que un equipo también es un recurso.

Durante el inicio de sesión, la autorización es el permiso de acceso a la máquina local; cuando se accede a un recurso compartido es el permiso de acceso al recurso.

A partir que se ha autenticado a la cuenta, comienza la segunda parte, verificar que el usuario tenga los privilegios necesarios para acceder al recurso y en la forma solicitada. Si inicia sesión, verifica si tiene el derecho de “Inicio de sesión interactivo”; y si intenta abrir un archivo, con acceso de lectura-escritura, por ejemplo, si tiene los permisos necesarios.

Recién cuando el sistema ha verificado que la cuenta está Autorizada para hacer lo que intenta, le da acceso.

Cuando iniciamos sesión, verifica identidad (Autenticación), luego controla si tenemos derecho de inicio de sesión interactivo (Autorización), y finalmente arma el escritorio de Windows.

Cuando nos conectamos a un recurso remoto, también verifica la identidad primero (Autentica), y luego controla si tenemos los permisos requeridos para acceder al recurso. La diferencia con el caso anterior es que estos procesos los ejecuta el equipo remoto al que estamos intentando acceder.

Es fácil ver que son dos procesos distintos: podemos verificar la identidad (Usuario-Contraseña) correcta, pero no estar autorizados para ejecutar determinada acción. Iniciamos sesión, pero recibimos acceso denegado sobre una carpeta por ejemplo

Grupo de Trabajo y Dominio ¿quién cumple qué funciones?

Desarrollaremos primero las importantes diferencias entre grupo de trabajo (Workgroup) y dominio, ya que tanto la autenticación como la autorización se desarrollan de formas diferentes en cada caso.

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 además 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.

Algo que habrán notado seguramente, es que con los sistemas operativos actuales como clientes, hay que crear una cuenta de máquina en el dominio, inclusive con los servidores miembros. Los equipos tienen cuenta en el dominio, se autentican 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á NTLM, 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, 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.

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 servidor 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. La solución a todo esto se llama Relaciones de Confianza entre Dominios que seguramente trataremos en otra nota.