1- El computador o servidor miembro busca un Domain Controller en su dominio para autenticar (si, esta información esta almacenada en el Registro de Windows). Recordemos que los objetos "computer" son un "security principal" así como los objetos "user" por lo cual también deben autenticar, cambiar contraseñas y demas...
2- Mediante el puerto 53 UDP se hace una petición al servidor DNS por todos los registros SRV de la zona ldap._tcp.
3- El DNS retorna al equipo la lista de DCs para el sitio o bien para el dominio.
4- El cliente hace una consulta LDAP para validar que dicho cliente existe en el directorio, acá se valida el nombre del equipo, el nombre del dominio al cual pertenece, el GUID y sAMAccountName (equipo01$). Esto se hace por medio de una consulta anónima, aun no se ha dado la autenticación.
5- Si el controlador encuentra que la información es correcta se envía una respuesta de "success" a la petición de LDAP.
6- Basado en la lista de controladores obtenida en el paso 3 el equipo envía un ping a estos, el primer controlador en responder será el que maneje la petición de autenticación (acá mi cabecita asume que la prioridad y peso de los registros SRV se toma en cuenta, si este es el mismo para todos [0 y 100 respectivamente] simplemente se escoge el orden de los equipos de forma aleatoria, similar a un Round Robin, realmente debo buscar más información al respecto, pero lo anterior sería lo más lógico basado en la teoría, claro mi lógica a veces es un poco extraña).
7- El equipo inicia una serie de conexiones TCP con el controlador que selecciono anteriormente. Se realizaran consultas al puerto de RPC (135 TCP), como sabemos dicho protocolo utiliza puertos aleatorios para la comunicación así que esta consulta nos dirá cual puerto debemos usar creando así las conexiones necesarias para realizar las comunicaciones RPC (RPC se puede limitar a usar puertos estáticos, lo cual disminuirá la cantidad de puertos habilitados en el firewall http://support.microsoft.com/kb/555381). También se establecerá comunicación mediante SMB (445 TCP), esto para File Sharing.
8- Una vez creadas las conexiones anteriores el equipo intentara enviar su petición de autenticación por el puerto 88 UDP, que es donde Kerberos escucha. Como sabemos UDP no ofrece garantía/confirmación de entrega por lo cual si este proceso falla se reintentara la transmisión, esta vez utilizando TCP. Este comportamiento también se pude manipular, forzando a que únicamente se utilice TCP (http://support.microsoft.com/?kbid=244474).
9- Basado en la información recibida del RPC Port Mapper (paso 7) el equipo creara una conexión TCP a dicho puerto, donde el AD Logon RPC Server está escuchando, toda información que se intercambia en este paso esta encriptada.
10- El controlador responde la petición de autenticación Kerberos brindando una llave de sesión, la cual será utilizada durante el proceso de autenticación con el controlador.
11- Utilizando dicha llave y la conexión establecida en el paso 9 se envía múltiples peticiones de autenticacion tipo RPC R_Logon al controlador.
12- Utilizando la conexión SMB creada anteriormente el equipo se conecta al volumen compartido IPC$. También se consulta al controlador si este sabe de algún Microsoft DFS Referral.
13- Utilizando la conexión SMB anterior el equipo realiza pruebas para determinar si la conexión al controlador es de alta velocidad (slow-link test). Dicha prueba determinara ciertos comportamientos futuros, como por ejemplo el proceso de ciertas políticas o también la uso/proceso de perfiles roaming. La prueba de slow-link consiste en un ping de 60 bytes el cual esta cronometrado, luego otro de 1514 bytes repitiendo ambos 3 veces, con la información de latencia se determina la velocidad del enlace y si este debe ser catalogado como slow-link (menor a los 500Kbps o cual sea el valor definido para este).
14- El equipo hará consultas al puerto 389 TCP sobre el dominio y contextos de nombre (consultas al rootDSE, al menos eso creo).
15- El equipo intentara hacer una conexión autenticada a LDAP, esto enviando una petición tipo Generic Security Service (GSS)SPNEGO.
16- Mediante LDAP el equipo averigua su lugar en la jerarquía de AD, con lo cual sabe que GPOs aplican a su sitio, dominio y/o Unidad Organizativa, esto mediante una consulta LDAP que le retorne el los atributos "gpLink" y "gpOptions" de cada contenedor.
17- Dicha consulta retornara el DN de los GPOs (si gusta ver una lista de sus políticas en AD navegue al contenedor de Policies, que se encuentra en el contenedor System en la partición de dominio).
18- El equipo mediante una petición SMB leerá del SYSVOL el GPC de cada GPO que le aplique. Eso si antes revisara por algún DFS Referal que le lleve al share más cercano (cuando aplica).
19- El equipo leerá y procesara el contenido de cada GPT.
20- El equipo utilizara NTP para hacer una sincronización de tiempo contra el controlador, esto en el caso ideal de que el NTP para nuestros clientes sea tipo NT5DS.
21- Por último el equipo determinara si se necesita realizar alguna transacción referente a certificados, esto al hacer una consulta LDAP a la partición de configuración, específicamente al contenedor CN=Public.Key.Services,CN=Services,CN=Configuration,DC=daemonroot,dc=com en búsqueda de objetos tipo "NTAuthCertificates" y "caCertificate".
Aunque todo esto suena a mucho trabajo realmente es algo rápido y sencillo, que en promedio dura unos 30/40 segundos... en la sana teoría =P
A partir de este punto ya se inicia el proceso de mostrarnos el prompt del Ctl+Alt+Del para así autenticarnos, pero eso ya es otro cuento y el Lobo Feroz hoy no está para contárnoslo...
No comments:
Post a Comment