Magic Quadrant™ para la gestión de acceso privilegiado 2025: Netwrix reconocida por cuarto año consecutivo. Descarga el informe.

Plataforma
Centro de recursosBlog
¿Qué es la delegación Kerberos? Una visión general de la delegación Kerberos

¿Qué es la delegación Kerberos? Una visión general de la delegación Kerberos

Nov 30, 2021

Propósito de la delegación de Kerberos

La delegación de Kerberos existe desde hace mucho tiempo (desde Windows Server 2000, para ser exactos). Pero a menudo, los ingenieros que trabajan con Active Directory no están familiarizados con todas las diferentes implementaciones de la delegación de Kerberos, sus usos y las formas en que pueden ser abusadas. Algunos incluso confunden la delegación de Kerberos con los permisos delegados.

El uso práctico de la delegación de Kerberos es permitir que una aplicación acceda a recursos alojados en un servidor diferente. Un ejemplo es cuando una aplicación, como un servidor web, necesita acceder a recursos para el sitio web alojado en otro lugar, como una base de datos SQL. En lugar de darle a la cuenta de servicio que ejecuta el servidor web acceso directo a la base de datos, puedes permitir que esa cuenta de servicio sea delegada al servicio del servidor SQL. Una vez que un usuario inicia sesión en el sitio web, la cuenta de servicio solicitará acceso al servicio del servidor SQL en nombre de ese usuario. Esto permite que el usuario acceda al contenido en la base de datos al que ha sido provisto, sin tener que provisionar ningún acceso a la cuenta de servicio del servidor web en sí.

Tipos de delegación de Kerberos

A lo largo de los años han evolucionado algunas variantes de la delegación Kerberos. La implementación original de Windows Server 2000 es la delegación sin restricciones. Desde entonces, han surgido versiones más estrictas de delegación que mejoran la seguridad: la delegación restringida y la delegación restringida basada en recursos. Profundizaré más en cada tipo de delegación a continuación.

Para configurar la delegación en una computadora o cuenta de usuario, utilice la pestaña Delegación en Active Directory Users and Computers, como se muestra a continuación. Tenga en cuenta que las cuentas de usuario deben tener un servicePrincipalName (SPN) establecido.

Image

Figura 1. Pestaña de delegación en Active Directory Users and Computers

La primera opción (en amarillo) le permite configurar una cuenta para que NO se le permita ser confiable para la delegación; esto se utiliza más comúnmente para cuentas sensibles o administrativas que nunca deberían usarse para la delegación. La segunda opción (en verde) le permite configurar una cuenta para delegación sin restricciones. La tercera opción (en rojo) le permite configurar una cuenta para delegación restringida.

Delegación sin restricciones

Esta es la implementación original de la delegación, y también la menos segura. ¿Qué hace realmente la delegación sin restricciones? Bajo el capó, cuando se configura la delegación sin restricciones, el atributo userAccountControl del objeto se actualiza para incluir la bandera “TRUSTED_FOR_DELEGATION”. Cuando un objeto se autentica en un host con delegación sin restricciones configurada, el ticket-granting ticket (TGT) de esa cuenta se almacena en memoria para que el host con delegación sin restricciones configurada pueda suplantar a ese usuario más tarde, si es necesario.

Imagina un escenario donde una cuenta privilegiada se autentica en un host con delegación sin restricciones configurada. Esa cuenta puede acceder a cualquier servicio configurado dentro del dominio como ese usuario privilegiado. Para llevarlo un paso más allá, ¿qué pasaría si hubiera formas de forzar a las cuentas privilegiadas a autenticarse en tu host automáticamente? Utilizando el “error de impresora”, puedes conseguir que un controlador de dominio se autentique en tu host, dejando el TGT para esa cuenta en memoria.

Dado que existen mecanismos como el “printer bug”, la delegación sin restricciones es muy insegura y no debería utilizarse si es posible evitarlo. Es importante señalar que, por defecto, los controladores de dominio están configurados con delegación sin restricciones. Sin embargo, dado que sus controladores de dominio deberían ser mucho más seguros que un servidor de aplicaciones aleatorio que aloja un servicio, no debería ser un problema.

Delegación restringida

Introducido en Windows Server 2003, la delegación restringida te permite configurar a qué servicios se puede delegar una cuenta. Esto, en teoría, limita la exposición potencial si ocurre un compromiso.

Image

Figura 2. TestUserA puede ser delegado al servicio HTTP/test.

Una restricción a tener en cuenta para la delegación restringida es que no funciona entre bosques.

Cuando se establece la delegación restringida en una cuenta, suceden dos cosas bajo el capó:

  • El atributo userAccountControl para el objeto se actualiza con la bandera “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION”.

  • El atributo msDS-AllowedToDelegateTo se llena con el SPN configurado en la pestaña de delegación.

Abusar de la delegación restringida es diferente a abusar de la delegación sin restricciones. Una forma común en la que puede ser abusada es si los atacantes logran comprometer la contraseña en texto plano o el hash NTLM de una cuenta de usuario configurada para delegación restringida. Utilizando una herramienta como Kekeo, son capaces de solicitar un TGT para la cuenta de la que tienen la contraseña, ejecutar la solicitud de TGS para cualquier usuario (siempre y cuando el usuario no esté marcado como 'Sensible'), e inyectar el ticket y acceder al servicio solicitado como ese usuario.

Delegación restringida basada en recursos

Introducido en Windows Server 2012, la delegación restringida basada en recursos cambia cómo se puede configurar la delegación restringida, y funcionará a través de una confianza. En lugar de especificar qué objeto puede delegar a qué servicio, el recurso que aloja el servicio especifica qué objetos pueden delegar a él. Desde el punto de vista administrativo, esto permite que el propietario del recurso controle quién puede acceder a él. Por ejemplo, en lugar de especificar con delegación restringida que la cuenta de servicio WebServer puede delegar al Servicio SQL para acceder a la base de datos, puede especificar en la cuenta de servicio del servidor SQL que la cuenta de servicio WebServer tiene permisos para delegar acceso a él.

La delegación restringida basada en recursos se configura al completar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity en el recurso objetivo con el SID del objeto que tiene permiso para delegar en él. Para configurar la delegación restringida basada en recursos, necesitas usar PowerShell; no hay un componente de GUI dentro de Active Directory Users and Computers y la página del Editor de Atributos no permite la modificación manual de este atributo.

Puede leer más sobre la Delegación Restringida Basada en Recursos y formas de abusar de ella aquí.

Identificación de la delegación de Kerberos existente

Ahora que comprendes algunos de los conceptos básicos de los diferentes tipos de delegación y algunas formas en que pueden ser abusados, quiero compartir contigo un método que puedes usar para entender qué tipos de delegación ya están configurados en tu entorno. Nos centraremos específicamente en resaltar escenarios inseguros, como la delegación sin restricciones configurada en objetos que no son controladores de dominio.

Aquí hay un script, que originalmente se publicó en la galería de Microsoft Technet, que identificará cuentas con delegación sin restricciones, delegación con restricciones y delegación basada en recursos configurada, resaltando información y posibles advertencias sobre las configuraciones que enumera:

      <#.Synopsis    Search the domain for accounts with Kerberos Delegation..DESCRIPTION    Kerberos Delegation is a security sensitive configuration. Especially    full (unconstrained) delegation has significant impact: any service    that is configured with full delegation can take any account that    authenticates to it, and impersonate that account for any other network    service that it likes. So, if a Domain Admin were to use that service,    the service in turn could read the hash of KRBRTG and immediately    effectuate a golden ticket. Etc :)    This script searches AD for regular forms of delegation: full, constrained,    and resource based. It dumps the account names with relevant information (flags)    and adds a comment field for special cases. The output is a PSObject that    you can use for further analysis.    Note regarding resource based delegation: the script dumps the target    services, not the actual service doing the delegation. I did not bother    to parse that out.    Main takeaway: chase all services with unconstrained delegation. If    these are _not_ DC accounts, reconfigure them with constrained delegation,    OR claim them als DCs from a security perspective. Meaning, that the AD    team manages the service and the servers it runs on..EXAMPLE   .Search-KerbDelegatedAccounts.ps1 | out-gridview.EXAMPLE   .Search-KerbDelegatedAccounts.ps1 -DN "ou=myOU,dc=sol,dc=local".NOTES    Version:   0.1 : first version.                    0.2 : expanded LDAP filter and comment field.    Author:         Willem Kasdorp, Microsoft.    Creation Date:  1/10/2016    Last modified:  4/11/2017#>[CmdletBinding()]Param(    # start the search at this DN. Default is to search all of the domain.    [string]$DN = (Get-ADDomain).DistinguishedName)$SERVER_TRUST_ACCOUNT = 0x2000$TRUSTED_FOR_DELEGATION = 0x80000$TRUSTED_TO_AUTH_FOR_DELEGATION= 0x1000000$PARTIAL_SECRETS_ACCOUNT = 0x4000000 $bitmask = $TRUSTED_FOR_DELEGATION -bor $TRUSTED_TO_AUTH_FOR_DELEGATION -bor $PARTIAL_SECRETS_ACCOUNT# LDAP filter to find all accounts having some form of delegation.# 1.2.840.113556.1.4.804 is an OR query.$filter = @"(&  (servicePrincipalname=*)  (|    (msDS-AllowedToActOnBehalfOfOtherIdentity=*)    (msDS-AllowedToDelegateTo=*)    (UserAccountControl:1.2.840.113556.1.4.804:=$bitmask)  )  (|    (objectcategory=computer)    (objectcategory=person)    (objectcategory=msDS-GroupManagedServiceAccount)    (objectcategory=msDS-ManagedServiceAccount)  ))"@ -replace "[sn]", ''$propertylist = @(    "servicePrincipalname",    "useraccountcontrol",    "samaccountname",    "msDS-AllowedToDelegateTo",    "msDS-AllowedToActOnBehalfOfOtherIdentity")Get-ADObject -LDAPFilter $filter -SearchBase $DN -SearchScope Subtree -Properties $propertylist -PipelineVariable account | ForEach-Object {    $isDC = ($account.useraccountcontrol -band $SERVER_TRUST_ACCOUNT) -ne 0    $fullDelegation = ($account.useraccountcontrol -band $TRUSTED_FOR_DELEGATION) -ne 0    $constrainedDelegation = ($account.'msDS-AllowedToDelegateTo').count -gt 0    $isRODC = ($account.useraccountcontrol -band $PARTIAL_SECRETS_ACCOUNT) -ne 0    $resourceDelegation = $account.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null    $comment = ""    if ((-not $isDC) -and $fullDelegation) {        $comment += "WARNING: full delegation to non-DC is not recommended!; "    }    if ($isRODC) {        $comment += "WARNING: investigation needed if this is not a real RODC; "    }    if ($resourceDelegation) {        # to count it using PS, we need the object type to select the correct function... broken, but there we are.        $comment += "INFO: Account allows delegation FROM other server(s); "    }    if ($constrainedDelegation) {        $comment += "INFO: constrained delegation service count: $(($account.'msDS-AllowedToDelegateTo').count); "    } [PSCustomobject] @{        samaccountname = $account.samaccountname        objectClass = $account.objectclass               uac = ('{0:x}' -f $account.useraccountcontrol)        isDC = $isDC        isRODC = $isRODC        fullDelegation = $fullDelegation        constrainedDelegation = $constrainedDelegation        resourceDelegation = $resourceDelegation        comment = $comment    }}
      

Image

Figura 3. Script de muestra para identificar delegaciones problemáticas

Cómo Netwrix puede ayudar

La solución de seguridad de Netwrix Active Directory te ayuda a proteger tu Active Directory de principio a fin. Puedes:

  • Identifique y mitigue vulnerabilidades en su Active Directory: permisos excesivos, administradores “ocultos”, cuentas obsoletas, weak passwords, y más.

  • Controle las configuraciones y permisos de AD, aplique políticas de password policies, y prevenga el robo de credenciales.

  • Detecte incluso amenazas avanzadas para detener a los actores maliciosos en su camino antes de que completen su misión.

  • Contenga de inmediato una violación de seguridad con acciones de respuesta automatizadas, minimizando el daño a su negocio.

  • Revise o recupérese de cambios maliciosos o inapropiados con un tiempo de inactividad mínimo.

Compartir en

Aprende más

Acerca del autor

Asset Not Found

Kevin Joyce

Director de Product Management

Director de Product Management en Netwrix. Kevin tiene una pasión por la ciberseguridad, específicamente en comprender las tácticas y técnicas que los atacantes utilizan para explotar los entornos de las organizaciones. Con ocho años de experiencia en product management, enfocándose en Active Directory y la seguridad de Windows, ha llevado esa pasión a ayudar a construir soluciones para que las organizaciones protejan sus identidades, infraestructura y datos.