Cosa rappresentano i principali di sicurezza esterni AD
I principali di sicurezza esterni AD sono oggetti segnaposto che consentono a un dominio di rappresentare identità di sicurezza che non conserva come normali utenti o gruppi locali. La loro presenza è un dato di inventario. Non dimostra un attacco, un'autorizzazione pericolosa o una relazione di trust compromessa. Esaminate il SID di ogni oggetto e i gruppi che lo utilizzano prima di decidere se occorre cambiare qualcosa.
La specifica Microsoft del contenitore Foreign Security Principals in MS-ADTS spiega il caso AD DS: il contesto dei nomi del dominio contiene un contenitore di oggetti foreignSecurityPrincipal che rappresentano principali di domini attendibili esterni alla foresta, consentendo a tali principali di far parte dei gruppi del dominio. Questo articolo riguarda AD DS, anziché le regole distinte del contenitore AD LDS.
Esiste anche un caso normale relativo ai SID noti. La spiegazione storica dei FSP di Microsoft, aggiornata l'ultima volta il 24 maggio 2016, descrive perché l'aggiunta di un'identità nota all'attributo member di un gruppo può creare un segnaposto: il riferimento di appartenenza richiede un nome distinto esistente. L'archivio raccomanda di esaminare memberOf prima di rimuovere un FSP. Documenta l'appartenenza ai gruppi; non dimostra che ogni riferimento in una ACL crei un FSP.
Le fonti tecniche e il comportamento del collector sono stati esaminati il 4 ottobre 2026. I comandi seguenti sono esempi basati sulla documentazione per un amministratore autorizzato; non sono stati eseguiti su un dominio di un cliente.
Come classificare il SID e le sue dipendenze
Partite da tre esiti: identità nota, identità esterna risolta e indeterminato. Sono decisioni di revisione, non livelli di gravità dedotti da un numero di oggetti. Conservate il SID nel registro anche quando uno strumento mostra un nome leggibile. I nomi sono utili per contattare i responsabili; il SID è l'identità referenziata.
L'attuale riferimento Microsoft sugli identificatori di sicurezza elenca le seguenti identità note:
| SID | Identità | Conseguenza per questa revisione |
|---|---|---|
S-1-5-11 | Utenti autenticati (Authenticated Users) | Classificare come noto; esaminare perché il gruppo che lo utilizza lo include |
S-1-5-4 | Interattivo (Interactive) | Classificare come noto; confermare l'appartenenza prevista con il responsabile del gruppo |
S-1-5-7 | Accesso anonimo (Anonymous Logon) | Classificare come noto; valutare l'uso effettivo anziché definirlo un account esterno |
S-1-1-0 | Mondo / Tutti (World / Everyone) | Classificare come noto; valutare l'ampiezza prevista del gruppo che lo utilizza |
Questo è un insieme di esempi, non una tabella di consultazione completa. Confrontate qualsiasi altro SID con il riferimento Microsoft prima di assegnargli un'etichetta. Noto significa identità riconosciuta, non accesso automaticamente appropriato. Un'appartenenza ampia può comunque meritare una revisione, ma eliminare il suo segnaposto non sostituisce l'esame della decisione di appartenenza.
Per un SID di account di dominio, identificate il dominio emittente e chiedete all'amministratore responsabile di quel dominio di confermare il principale esatto. Registrate il dominio di origine, l'identità attuale, il responsabile di business e lo scopo della sua appartenenza. La sola risoluzione riuscita di un nome non dimostra che il gruppo sia ancora necessario. Il solo fallimento della risoluzione non dimostra che il principale sia stato eliminato.
Mantenete esplicita l'incertezza. Il registro di revisione deve rispondere a quattro domande: la raccolta è stata completata, quali gruppi utilizzano l'oggetto, è possibile contattare il partner di trust pertinente e chi può approvare la decisione di business? Una domanda senza risposta mantiene l'oggetto nella categoria indeterminata.
Rilevamento: inventariare SID, memberOf e contesto di trust
Passaggio 1: raccogliere gli oggetti indipendentemente dal conteggio
Utilizzate un host di amministrazione Windows autorizzato con il modulo PowerShell ActiveDirectory. Selezionate consapevolmente un controller di dominio e registrate host, dominio, ora della raccolta ed eventuali errori. La documentazione Microsoft di Get-ADRootDSE espone defaultNamingContext; usatelo per costruire il DN del contenitore specifico del dominio anziché copiare il percorso di un altro dominio.
L'inventario seguente adatta i parametri documentati di query LDAP di Get-ADObject. Il filtro è fisso, gli attributi aggiuntivi sono espliciti e $null per ResultSetSize evita un limite intenzionale al numero di risultati.
Import-Module ActiveDirectory
$dc = 'dc01.corp.example'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$base = 'CN=ForeignSecurityPrincipals,' + $root.defaultNamingContext
$fsps = @(Get-ADObject -Server $dc -SearchBase $base -SearchScope Subtree `
-LDAPFilter '(objectClass=foreignSecurityPrincipal)' `
-Properties objectSID,memberOf -ResultPageSize 256 `
-ResultSetSize $null -ErrorAction Stop)
$fsps | Select-Object DistinguishedName,ObjectGUID,objectSID,memberOf
Per un client LDAP, la richiesta equivalente usa quel contenitore come base di ricerca, l'ambito sottoalbero, (objectClass=foreignSecurityPrincipal) come filtro e distinguishedName, objectGUID, objectSid e memberOf come attributi richiesti. Completate la paginazione, preservate gli attributi multivalore e conservate separatamente i fallimenti e i risultati vuoti. Non costruite stringhe SID a partire dai nomi visualizzati.
Non procedete alla pulizia se la query fallisce, viene interrotta o l'account non può leggere le proprietà richieste. Un inventario vuoto derivante da una lettura completata e un inventario non disponibile sono esiti diversi. Per più domini, ripetete la raccolta con il contesto specifico di ciascun dominio e mantenete separati questi registri.
Passaggio 2: esaminare i gruppi che utilizzano l'oggetto
Il riferimento dello schema Microsoft di memberOf lo identifica come i nomi distinti dei gruppi a cui appartiene l'oggetto. Trattate i riferimenti restituiti come l'elenco iniziale dei gruppi che lo utilizzano, non come un rapporto sugli accessi effettivi. Seguite separatamente l'annidamento dei gruppi e le dipendenze delle risorse prima di giudicare l'impatto.
Selezionate un FSP tramite il DN registrato, senza prendere la prima riga. Questo esempio utilizza i parametri documentati di identità e proprietà aggiuntive di Get-ADGroup per esaminare ogni gruppo restituito:
$fspDn = Read-Host 'Exact FSP distinguished name from the inventory'
$fsp = Get-ADObject -Identity $fspDn -Server $dc `
-Properties objectSID,memberOf -ErrorAction Stop
foreach ($groupDn in $fsp.memberOf) {
Get-ADGroup -Identity $groupDn -Server $dc `
-Properties member,memberOf,managedBy,description -ErrorAction Stop |
Select-Object DistinguishedName,GroupScope,GroupCategory, `
member,memberOf,managedBy,description
}
Verificate che i valori member del gruppo contengano il DN esatto del FSP. Chiedete al responsabile del gruppo quale applicazione o risorsa ne dipende, se un'acquisizione o una migrazione è ancora in corso e come verificare l'accesso previsto. managedBy e la descrizione possono fornire indizi per i contatti; non sostituiscono la conferma di un responsabile che risponda della decisione. Un campo del responsabile vuoto è un'attività da approfondire, non un permesso di eliminare.
Passaggio 3: risolvere senza trasformare i fallimenti in un verdetto di oggetto orfano
Microsoft documenta SecurityIdentifier.Translate e la sua IdentityNotMappedException quando i riferimenti di identità non possono essere tradotti. Questo esempio conserva il fallimento come prova:
$sid = [System.Security.Principal.SecurityIdentifier]$fsp.objectSID
try {
$account = $sid.Translate([System.Security.Principal.NTAccount])
[pscustomobject]@{ SID = $sid.Value; Account = $account.Value }
} catch {
[pscustomobject]@{ SID = $sid.Value; LookupError = $_.Exception.Message }
}
La risoluzione usa il contesto Windows dell'host di amministrazione. Non accetta un controller di dominio partner selezionato e non dimostra il corretto funzionamento del trust. Conservate host ed errore, identificate il dominio emittente atteso, verificate la risoluzione dei nomi e la connettività necessaria con i suoi amministratori e confermate se il SID esatto esiste ancora in quel dominio. Indagate sui partner inaccessibili e sui trust dismessi prima di usare la parola orfano. Non indebolite le impostazioni di trust per far riuscire una risoluzione.
La documentazione Microsoft di Get-ADTrust fornisce questo comando esatto di enumerazione:
Get-ADTrust -Filter *
Utilizzate gli oggetti di dominio attendibile restituiti come contesto, registrando il dominio interrogato. La loro presenza è una prova di configurazione, non un test di connettività da un'estremità all'altra né una prova che un particolare SID esterno sia risolvibile. Una volta identificata un'effettiva identità esterna, il controllo del filtro SID e dell'autenticazione selettiva dei trust fornisce la revisione separata dei controlli di trust.
Se invece la domanda è se un destinatario di autorizzazioni non risolto detenga un'autorizzazione pericolosa, utilizzate il controllo delle ACE pericolose per destinatari non risolti e tra domini. Questo esamina le autorizzazioni DACL; questo inventario classifica gli oggetti FSP esistenti e i gruppi che li utilizzano. Nessuna delle due revisioni sostituisce l'altra.
Correzione: rimuovere solo un riferimento dimostrato superfluo (Remediation)
Passaggio 1: approvare la classificazione e l'ambito
Conservate le appartenenze note ed esterne necessarie. Lasciate invariati gli oggetti indeterminati finché restano aperte questioni di raccolta, connettività o responsabilità. Per un riferimento candidato alla dismissione, conservate il SID esatto, il DN e il GUID del FSP, i DN dei gruppi che lo utilizzano, la conferma del partner, la decisione del responsabile e i test pertinenti dell'applicazione. Concordate una finestra di modifica e un ripristino in grado di ristabilire l'appartenenza prevista.
Rendete specifica la decisione: quale appartenenza a un gruppo è superflua, perché e quali accessi devono continuare in seguito? Se solo un gruppo ha dismesso la propria dipendenza, rimuovete soltanto quell'appartenenza. Altri gruppi possono ancora aver bisogno dello stesso segnaposto. Non fate dell'eliminazione dell'oggetto il primo passaggio di una revisione delle appartenenze.
Passaggio 2: visualizzare in anteprima una modifica di appartenenza approvata
La documentazione Microsoft di Set-ADGroup supporta la rimozione di un valore specifico di una proprietà tramite il suo nome visualizzato LDAP, oltre a WhatIf e alla conferma. Questo esempio adattato prende di mira un solo DN member su un controller di dominio scrivibile:
$groupDn = Read-Host 'Exact approved consuming group distinguished name'
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop
Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} -WhatIf
Esaminate prima il destinatario e l'appartenenza salvata. WhatIf mostra un'anteprima dell'operazione; non verifica l'accesso dell'applicazione né garantisce che una scrittura successiva riesca. Solo dopo che il responsabile ha approvato questa esatta rimozione, eseguite la singola modifica con conferma e rileggete il gruppo:
Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} `
-Confirm:$true -ErrorAction Stop
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop
Passaggio 3: convalidare l'accesso prima dell'eventuale pulizia dell'oggetto
Confermate che l'appartenenza approvata sia cambiata, tenete conto della replica e del contesto di autenticazione dell'ambiente e chiedete al responsabile dell'applicazione di verificare sia l'accesso previsto sia la dipendenza dismessa. Una scrittura riuscita non è un test di accesso. Registrate i risultati effettivi nel registro della modifica anziché dichiarare il successo sulla base di un conteggio di inventario inferiore.
Raccogliete nuovamente le appartenenze del FSP e indagate sulle dipendenze rimanenti. Un memberOf vuoto non dimostra da solo che un SID sia inutilizzato nelle ACL delle risorse o nella configurazione delle applicazioni. Se si dimostra che l'oggetto stesso è superfluo, la sua pulizia è un'azione separata ed esplicitamente approvata. Il riferimento Microsoft di Remove-ADObject documenta la rimozione di un singolo oggetto; visualizzate l'anteprima del GUID registrato solo dopo questi controlli:
Remove-ADObject -Identity $fsp.ObjectGUID -Server $dc -WhatIf
Questa anteprima non esegue alcuna eliminazione. Non trasformatela in una pipeline sull'intero contenitore e non rimuovete il contenitore stesso. Conservate insieme la decisione di pulizia, il piano di ripristino e la verifica finale dell'accesso.
Come EtcSec rileva questo caso
Il controllo FOREIGN_SECURITY_PRINCIPALS di EtcSec riporta DomainInfo.ForeignSecurityPrincipalsCount. Il metodo Detect() esaminato inizializza il conteggio a zero, copia il campo quando esiste DomainInfo e restituisce un rilievo di gravità Medium che contiene quel conteggio. Un DomainInfo mancante produce quindi zero. I dettagli per un conteggio positivo aggiungono una precisazione, non prove per oggetto o una classificazione dei SID.
Il provider LDAP esegue una ricerca paginata nel sottoalbero di CN=ForeignSecurityPrincipals,<baseDN> usando (objectClass=foreignSecurityPrincipal). Richiede soltanto distinguishedName e assegna il numero di voci restituite quando la ricerca riesce. Un errore di ricerca lascia il campo al suo valore iniziale di zero. Questo campo non espone alcun indicatore di successo della raccolta che distingua quel fallimento da un risultato vuoto ottenuto correttamente.
Il controllo non espone SID individuali, memberOf, responsabili, nomi risolti, connettività di trust o autorizzazioni effettive. Il suo conteggio mescola segnaposto noti e riferimenti esterni reali. Non può identificare un orfano, contare i trust, dimostrare l'esposizione tra foreste o stabilire che zero significhi un inventario pulito. La raccolta e la classificazione indipendenti illustrate sopra forniscono le prove necessarie per una decisione. Questa procedura non include alcuna eliminazione automatica.
Il testo esplicativo del collector generalizza inoltre la creazione dei segnaposto ai riferimenti nelle ACL. La fonte storica Microsoft usata qui dimostra il caso member; quella formulazione più ampia non viene ripetuta come regola verificata. Trattate il rilievo come un invito a esaminare gli oggetti sottostanti e le loro dipendenze, poi conservate o modificate soltanto ciò che le prove giustificano.
Esplora le pagine di identity security collegate a questo tema
