> For the complete documentation index, see [llms.txt](https://infra.desdes.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infra.desdes.xyz/protocolos-de/autenticacion.md).

# Autenticacion

Autorizacion en AD:

Existen dos protocolos de autorizacion en AD los cuales son Kerberos y NTLM.

## Kerberos

La autentiacion por Kerberos se realiza mediante el protocolo Kerberos. El usuario se comunica con el DC o KDC con quien realiza una comunicacion para validar las credenciales y luego de ello se puede comunicar con el computador al cual desea acceder.

<figure><img src="/files/ICXREFnnEbFuL1xw5QW4" alt=""><figcaption></figcaption></figure>

Podemos dividir la comunicacion de kerberos en 2 Flujos principales.

### Usuario <--> KDC

1. El Usuario realiza una solicitud para obtener un TGT (Ticket Granting Ticket) el cual seria un ticket que te permite obtener tickets de servicios.
2. El servidor responde al usuario con el TGT. Con ello, el usuario puede solicitar el ticket de servicio.
3. El Usuario envia la solicitud del ticket TGS (Ticket Granting Service) mas la autenticacion del mismo.
4. El servidor responde con el ticket y la llave o key de sesión.

### Usuario <--> Computador

5. Luego, con el ticket de servicio (TGS) creado, el usuario puede realizar la consulta al servicio de un computador en especifico.
6. El server le responde si la autenticacion es valida o no y realiza toda la comunicacion correspondiente.

#### Tickets

Como podemos ver, tenemos dos tipos de Tickets, TGT y TGS ambos se encriptan pero con llaves diferentes.

#### TGT

El TGT, como ya vimos es un ticket que sirve para identificar al usuario con el DC. Por ello este va a ser cifrado con la firma del usuario KRBTGT. Si se obtiene la firma de este usuario, se podrian crear Tickets impersonando usuarios con el DC (Golden Ticket).

#### TGS

El TGS, es un ticket que sirve para identificar identificar un usuario con un servicio dentro de un computador para poder utilizar sus recursos. Por ello este es cifrado con la firma del Computador. Si se obtiene la firma de este computador, se podria crear Tickets impersonando servicios (Silver Ticket).

A diferencia del Golden Ticket, el Silver ticket no requiere de conexion al DC ya que utiliza la firmal del computador, no de un usuario que se almacene en el DC esclusivamente. Por ello se dice que el Silver Ticket puede ser generado de manera OFFLINE.

Aca adjunto mas informacion sobre kerberos.

{% embed url="<https://www.tarlogic.com/es/blog/como-funciona-kerberos/>" %}

{% embed url="<https://www.tarlogic.com/es/blog/como-atacar-kerberos/>" %}

{% embed url="<https://www.tarlogic.com/es/blog/kerberos-iii-como-funciona-la-delegacion/>" %}

## NTLM

La autenticacion por NTLM se realiza entre el usuario y la PC, luego la pc se comunica con el DC para realizar la validacion de las credenciales, en caso que no pueda conectarse al DC utiliza las credenciales almacenadas en el cache.

<figure><img src="/files/jvK4kLahMfFHIjtilIDR" alt=""><figcaption><p>NTLM pass-through authentication</p></figcaption></figure>

* El usuario inicia sesión en el escritorio del ordenador (denominado Cliente) introduciendo el nombre de usuario y la contraseña. El cliente envía un mensaje NTLM NEGOTIATE\_MESSAGE para solicitar autenticación al servidor.
* El servidor envía un NTLM CHALLENGE\_MESSAGE (\[MS-NLMP] sección 2.2.1.2) al cliente.

  El cliente responde al reto firmándolo con su clave y enviando la respuesta en un NTLM AUTHENTICATE\_MESSAGE al servidor.
* El servidor reenvía la respuesta del cliente al controlador de dominio en un mensaje NETLOGON\_NETWORK\_INFO.
* El controlador de dominio verifica la firma de la respuesta y devuelve el resultado al servidor en un mensaje NETLOGON\_VALIDATION\_SAM\_INFO4. Si la verificación se realiza correctamente, el mensaje contiene el PAC del usuario con los datos de autorización. Si la verificación no tiene éxito, se deniega el inicio de sesión.

#### Ref

{% embed url="<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-apds/5bfd942e-7da5-494d-a640-f269a0e3cc5d>" %}

#### Observaciones

La comunicación ya sea Kerberos o NTLM se envia cifrada, pero... El formato antes del cifrado es User:Pass o User:Hash?. \[D004]&#x20;

Kerberos como NTLM son protocolos algo antiguos pero usados hasta el dia de hoy, cada uno para algo en especifico, NTLM no puede morir porque es requerido en muchos servicios ya sean Legacy  o Legados.

**Luego de ello, existen un protocolo que decide en los sistemas y dependiendo de que requisitos tenga el sistema si es que este usa Kerberos o NTLM como autenticacion.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://infra.desdes.xyz/protocolos-de/autenticacion.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.