Magic Quadrant™ per la gestione degli accessi privilegiati 2025: Netwrix riconosciuta per il quarto anno consecutivo. Scarica il report.

Piattaforma
Centro risorseBlog
Cos'è la Delega Kerberos? Una panoramica della Delega Kerberos

Cos'è la Delega Kerberos? Una panoramica della Delega Kerberos

Nov 30, 2021

Scopo della delega Kerberos

La delega Kerberos esiste da molto tempo (dal Windows Server 2000, per essere precisi). Ma molto spesso gli ingegneri che lavorano con Active Directory non sono a conoscenza di tutte le varie implementazioni della delega Kerberos, dei loro utilizzi e dei modi in cui possono essere abusate. Alcuni confondono addirittura la delega Kerberos con i permessi delegati.

L'uso pratico della delega Kerberos è quello di abilitare un'applicazione ad accedere a risorse ospitate su un server diverso. Un esempio è quando un'applicazione, come un server web, necessita di accedere a risorse per il sito web ospitato altrove, come un database SQL. Invece di dare all'account di servizio che gestisce il server web l'accesso diretto al database, è possibile consentire che tale account di servizio venga delegato al servizio del server SQL. Una volta che un utente effettua l'accesso al sito web, l'account di servizio richiederà l'accesso al servizio del server SQL per conto dell'utente. Questo permette all'utente di ottenere l'accesso ai contenuti nel database a cui è stato provisionato, senza dover provisionare alcun accesso all'account di servizio del server web stesso.

Tipi di delega Kerberos

Nel corso degli anni sono state sviluppate diverse varianti della delega Kerberos. L'implementazione originale di Windows Server 2000 è la delega non vincolata. Da allora, sono emerse versioni più rigorose della delega che migliorano la sicurezza: la delega vincolata e la delega vincolata basata sulle risorse. Approfondirò ogni tipo di delega qui di seguito.

Per configurare la delega su un computer o un account utente, utilizzare la scheda Delega in Active Directory Users and Computers, come mostrato di seguito. Notare che gli account utente devono avere un servicePrincipalName (SPN) impostato.

Image

Figura 1. Scheda Delega in Active Directory Users and Computers

La prima opzione (in giallo) consente di configurare un account in modo che NON sia consentito fidarsi per la delega; ciò è più comunemente utilizzato per account sensibili o amministrativi che non dovrebbero mai essere utilizzati per la delega. La seconda opzione (in verde) consente di configurare un account per la delega senza restrizioni. La terza opzione (in rosso) consente di configurare un account per la delega vincolata.

Delega non vincolata

Questa è l'implementazione originale della delega, ed è anche la meno sicura. Cosa fa effettivamente la delega senza vincoli? Sotto il cofano, quando viene configurata la delega senza vincoli, l'attributo userAccountControl dell'oggetto viene aggiornato per includere il flag “TRUSTED_FOR_DELEGATION”. Quando un oggetto si autentica su un host con delega senza vincoli configurata, il ticket-granting ticket (TGT) per quell'account viene memorizzato nella memoria in modo che l'host con delega senza vincoli configurata possa impersonare quell'utente in seguito, se necessario.

Immagina uno scenario in cui un account privilegiato si autentica su un host con delega illimitata configurata. Quell'account può accedere a qualsiasi servizio configurato all'interno del dominio come quell'utente privilegiato. Per andare oltre, cosa succederebbe se ci fossero modi per forzare gli account privilegiati ad autenticarsi automaticamente sul tuo host? Utilizzando il “bug della stampante”, puoi far autenticare un controller di dominio sul tuo host, lasciando il TGT per quell'account nella memoria.

Poiché esistono meccanismi come il “bug della stampante”, la delega senza restrizioni è molto insicura e non dovrebbe essere utilizzata se possibile. Da notare che, per impostazione predefinita, i controller di dominio sono configurati con delega senza restrizioni. Tuttavia, poiché i vostri controller di dominio dovrebbero essere molto più sicuri di un server applicativo casuale che ospita un servizio, non dovrebbe rappresentare un problema.

Delega vincolata

Introdotto in Windows Server 2003, la delega vincolata consente di configurare a quali servizi può essere delegato un account. Questo, in teoria, limita la potenziale esposizione in caso di compromissione.

Image

Figura 2. TestUserA può essere delegato al servizio HTTP/test.

Un limite da notare per la delega vincolata è che non funziona tra foreste diverse.

Quando la delega vincolata è impostata su un account, si verificano due cose dietro le quinte:

  • L'attributo userAccountControl per l'oggetto viene aggiornato con il flag “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION”.

  • L'attributo msDS-AllowedToDelegateTo viene popolato con lo SPN configurato nella scheda di delega.

Abusare della delega vincolata è diverso dall'abusare della delega non vincolata. Un modo comune in cui può essere abusata è se gli aggressori riescono a compromettere la password in chiaro o l'hash NTLM di un account utente configurato per la delega vincolata. Utilizzando uno strumento come Kekeo, sono in grado di richiedere un TGT per l'account di cui hanno la password, eseguire la richiesta TGS per qualsiasi utente (purché l'utente non sia contrassegnato come ‘Sensibile’), e poi iniettare il ticket e accedere al servizio richiesto come quell'utente.

Delega vincolata basata sulle risorse

Introdotto in Windows Server 2012, la delega vincolata basata su risorse cambia il modo in cui è possibile configurare la delega vincolata, e funzionerà attraverso una trust. Invece di specificare quale oggetto può delegare a quale servizio, la risorsa che ospita il servizio specifica quali oggetti possono delegarle. Da un punto di vista amministrativo, ciò consente al proprietario della risorsa di controllare chi può accedervi. Ad esempio, invece di specificare con la delega vincolata che l'account del servizio WebServer può delegare al Servizio SQL per accedere al database, è possibile specificare sull'account del servizio SQL server che l'account del servizio WebServer ha i permessi per delegare l'accesso ad esso.

La delega vincolata basata sulle risorse è configurata popolando l'attributo msDS-AllowedToActOnBehalfOfOtherIdentity sulla risorsa target con il SID dell'oggetto che è autorizzato a delegare ad essa. Per configurare la delega vincolata basata sulle risorse, è necessario utilizzare PowerShell; non esiste un componente GUI all'interno di Active Directory Users and Computers e la pagina dell'Attribute Editor non consente la modifica manuale di questo attributo.

Puoi leggere di più sulla Resource-Based Constrained Delegation e sui modi per abusarne qui.

Identificazione della Delega Kerberos Esistente

Ora che hai compreso alcuni degli aspetti fondamentali dei diversi tipi di delega e alcuni modi in cui possono essere abusati, voglio condividere con te un metodo che puoi utilizzare per capire quali tipi di delega sono già configurati nel tuo ambiente. Ci concentreremo specificamente su scenari insicuri, come la delega non vincolata configurata su oggetti diversi dai controller di dominio.

Ecco uno script, originariamente pubblicato nella galleria Microsoft Technet, che identificherà gli account con delega non vincolata, vincolata e basata su risorse configurate, evidenziando informazioni e potenziali avvisi sulle configurazioni elencate:

      <#.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 di esempio per identificare deleghe problematiche

Come Netwrix può aiutare

La soluzione di sicurezza Netwrix Active Directory ti aiuta a proteggere il tuo Active Directory da un capo all'altro. Puoi:

  • Identificare e mitigare le vulnerabilità nel vostro Active Directory: permessi eccessivi, amministratori “ombra”, account inutilizzati, weak passwords, e altro ancora.

  • Controlla le configurazioni e i permessi di AD, applica delle password policies forti e previeni il furto di credenziali.

  • Rileva anche le minacce avanzate per fermare i malintenzionati prima che portino a termine la loro missione.

  • Contenete istantaneamente una violazione della sicurezza con azioni di risposta automatizzate, minimizzando i danni per la vostra azienda.

  • Ripristina o recupera da modifiche dannose o comunque improprie con un tempo di inattività minimo.

Condividi su

Scopri di più

Informazioni sull'autore

Asset Not Found

Kevin Joyce

Direttore della Product Management

Direttore di Product Management presso Netwrix. Kevin ha una passione per la sicurezza informatica, in particolare per comprendere le tattiche e le tecniche che gli aggressori utilizzano per sfruttare gli ambienti delle organizzazioni. Con otto anni di esperienza nel product management, concentrandosi su Active Directory e la sicurezza di Windows, ha trasformato quella passione nell'aiutare a costruire soluzioni per le organizzazioni per proteggere le loro identità, infrastrutture e dati.