Principais externos no AD: classificar SIDs antes da limpeza

O que representam os principais externos no AD

Os principais externos no AD são objetos de representação de identidades de segurança que permitem a um domínio representar identidades que não armazena como utilizadores ou grupos locais comuns. A sua presença é um facto de inventário. Não demonstra um ataque, uma permissão perigosa ou uma relação de confiança com problemas. Analise a SID de cada objeto e os grupos que o utilizam antes de decidir se algo deve mudar.

A especificação MS-ADTS da Microsoft para o contentor Foreign Security Principals explica o caso do AD DS: o contexto de nomenclatura do domínio contém um contentor de objetos foreignSecurityPrincipal que representam principais de domínios de confiança externos à floresta, permitindo que esses principais integrem grupos no domínio. Este artigo aborda o AD DS, em vez das regras separadas para contentores do AD LDS.

Existe também o caso normal de uma SID well-known. A explicação histórica da Microsoft sobre FSP, atualizada pela última vez em 24 de maio de 2016, descreve por que adicionar uma identidade bem conhecida ao atributo member de um grupo pode criar um objeto de representação: a referência de associação precisa de um nome distinto existente. O arquivo recomenda analisar memberOf antes de remover um FSP. Documenta a associação a grupos; não estabelece que todas as referências em ACL criam um FSP.

As fontes técnicas e o comportamento do coletor foram revistos em 4 de outubro de 2026. Os comandos abaixo são exemplos baseados na documentação para um administrador autorizado; não foram executados num domínio de cliente.

Como classificar a SID e as suas dependências

Comece com três resultados: identidade bem conhecida, identidade externa resolvida e indeterminada. São decisões de análise, não níveis de gravidade inferidos a partir de uma quantidade de objetos. Mantenha a SID no registo mesmo quando uma ferramenta apresenta um nome legível. Os nomes são úteis para contactar os responsáveis; a SID é a identidade referenciada.

A referência atual da Microsoft sobre identificadores de segurança enumera as seguintes identidades bem conhecidas:

Este é um conjunto de exemplos, não uma tabela de consulta completa. Compare qualquer outra SID com a referência da Microsoft antes de lhe atribuir uma classificação. Well-known significa uma identidade reconhecida, não acesso automaticamente adequado. Uma associação abrangente pode continuar a justificar uma análise, mas eliminar o seu objeto de representação não substitui a revisão da decisão de associação.

Para uma SID de conta de domínio, identifique o domínio emissor e peça ao administrador responsável por esse domínio que confirme o principal exato. Registe o domínio de origem, a identidade atual, o responsável de negócio e a finalidade da associação. Uma resolução de nome bem-sucedida, por si só, não prova que o grupo ainda seja necessário. Uma resolução falhada, por si só, não prova que o principal tenha sido eliminado.

Mantenha a incerteza explícita. O registo de análise deve responder a quatro perguntas: a recolha foi concluída, que grupos utilizam o objeto, é possível contactar o parceiro de confiança relevante e quem pode aprovar a decisão de negócio? Uma pergunta sem resposta mantém o objeto na categoria indeterminada.

Deteção: inventariar SID, memberOf e contexto de confiança

Passo 1: recolher os objetos independentemente da contagem

Utilize um computador Windows de administração autorizado com o módulo PowerShell ActiveDirectory. Escolha deliberadamente um controlador de domínio e registe o computador, o domínio, a hora da recolha e quaisquer erros. A documentação da Microsoft sobre Get-ADRootDSE disponibiliza defaultNamingContext; utilize-o para construir o DN do contentor específico do domínio, em vez de copiar o caminho de outro domínio.

O inventário seguinte adapta os parâmetros documentados de consulta LDAP de Get-ADObject. O filtro é fixo, os atributos adicionais são explícitos e $null em ResultSetSize evita um limite intencional ao número de resultados.

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

Para um cliente LDAP, o pedido equivalente utiliza esse contentor como base de pesquisa, o âmbito de subárvore, (objectClass=foreignSecurityPrincipal) como filtro e distinguishedName, objectGUID, objectSid e memberOf como atributos pedidos. Conclua toda a paginação, preserve os atributos com múltiplos valores e guarde as falhas separadamente dos resultados vazios. Não construa cadeias SID a partir de nomes de apresentação.

Não avance para a limpeza se a consulta falhar, for interrompida ou se a conta não conseguir ler as propriedades necessárias. Um inventário vazio obtido numa leitura concluída e um inventário indisponível são resultados diferentes. Para vários domínios, repita a recolha com o contexto próprio de cada domínio e mantenha esses registos separados.

Passo 2: analisar os grupos que utilizam o objeto

A referência de esquema da Microsoft para memberOf identifica-o como os nomes distintos dos grupos aos quais o objeto pertence. Trate as referências devolvidas como a lista inicial de grupos que o utilizam, não como um relatório de acesso efetivo. Analise separadamente o aninhamento de grupos e as dependências de recursos antes de avaliar o impacto.

Selecione um FSP pelo seu DN registado, em vez de escolher a primeira linha. Este exemplo utiliza os parâmetros documentados de identidade e propriedades adicionais de Get-ADGroup para analisar cada grupo devolvido:

$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
}

Verifique se os valores de member do grupo contêm o DN exato do FSP. Pergunte ao responsável pelo grupo que aplicação ou recurso depende dele, se uma aquisição ou migração ainda está ativa e como testar o acesso pretendido. managedBy e a descrição podem fornecer pistas de contacto; não substituem a confirmação de um responsável que assuma a decisão. Um campo de responsável vazio é uma tarefa de acompanhamento, não uma autorização para eliminar.

Passo 3: resolver sem transformar falhas num veredicto de objeto órfão

A Microsoft documenta SecurityIdentifier.Translate e a sua IdentityNotMappedException quando não é possível traduzir referências de identidade. Este exemplo preserva a falha como evidência:

$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 }
}

A resolução utiliza o contexto Windows do computador de administração. Não aceita um DC parceiro selecionado e não demonstra a integridade da relação de confiança. Preserve o computador e o erro, identifique o domínio emissor esperado, verifique a resolução de nomes e a conectividade necessária com os seus administradores e confirme se a SID exata ainda existe nesse domínio. Investigue parceiros inacessíveis e relações de confiança desativadas antes de utilizar a palavra órfão. Não enfraqueça as definições de confiança para fazer uma resolução funcionar.

A documentação da Microsoft sobre Get-ADTrust apresenta exatamente este comando de enumeração:

Get-ADTrust -Filter *

Utilize os objetos de domínio de confiança devolvidos como contexto, registando o domínio consultado. A sua presença é evidência de configuração, não um teste de conectividade de ponta a ponta nem uma prova de que uma determinada SID externa é resolvida. Depois de identificar uma identidade externa real, a auditoria de filtragem SID e autenticação seletiva em relações de confiança fornece a análise separada dos controlos de confiança.

Se a questão for, em vez disso, saber se um destinatário de permissões não resolvido possui uma concessão perigosa, utilize a auditoria de ACEs perigosas para destinatários não resolvidos e entre domínios. Essa análise examina permissões DACL; este inventário classifica os objetos FSP existentes e os grupos que os utilizam. Nenhuma análise substitui a outra.

Remediação: remover apenas uma referência comprovadamente desnecessária (Remediation)

Passo 1: aprovar a classificação e o âmbito

Mantenha as associações well-known e externas necessárias. Deixe os objetos indeterminados inalterados enquanto existirem perguntas em aberto sobre recolha, conectividade ou responsabilidade. Para uma referência candidata a desativação, guarde a SID exata, o DN e GUID do FSP, os DNs dos grupos que o utilizam, a confirmação do parceiro, a decisão do responsável e os testes de aplicação relevantes. Acorde uma janela de alteração e um plano de reversão que permita restaurar a associação pretendida.

Torne a decisão específica: que associação a um grupo é desnecessária, porquê e que acessos devem continuar a funcionar depois? Se apenas um dos grupos que utilizam o objeto deixou de depender dele, remova apenas essa associação. Outros grupos podem continuar a precisar do mesmo objeto de representação. Não faça da eliminação do objeto o primeiro passo de uma análise de associações.

Passo 2: pré-visualizar uma alteração de associação aprovada

A documentação da Microsoft sobre Set-ADGroup permite remover um valor específico de uma propriedade através do seu nome de apresentação LDAP, além de suportar WhatIf e confirmação. Este exemplo adaptado visa um DN de member num DC com capacidade de escrita:

$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

Analise primeiro o alvo e a associação guardada. WhatIf pré-visualiza a operação; não testa o acesso da aplicação nem garante que uma escrita posterior será bem-sucedida. Só depois de o responsável aprovar esta remoção exata, execute a alteração individual com confirmação e volte a ler o grupo:

Set-ADGroup -Identity $groupDn -Server $dc -Remove @{member=$fspDn} `
    -Confirm:$true -ErrorAction Stop
Get-ADGroup -Identity $groupDn -Server $dc -Properties member -ErrorAction Stop

Passo 3: validar o acesso antes da limpeza opcional do objeto

Confirme que a associação aprovada foi alterada, tenha em conta a replicação e o contexto de autenticação do ambiente e peça ao responsável pela aplicação que verifique tanto o acesso pretendido como a dependência desativada. Uma escrita bem-sucedida não é um teste de acesso. Registe os resultados reais no registo de alteração, em vez de declarar sucesso a partir de uma contagem de inventário inferior.

Volte a recolher a associação do FSP e investigue as dependências restantes. Um memberOf vazio não estabelece, por si só, que uma SID não seja utilizada em ACLs de recursos ou na configuração de aplicações. Se o próprio objeto for comprovadamente desnecessário, a sua limpeza é uma ação separada, explicitamente aprovada. A referência da Microsoft para Remove-ADObject documenta a remoção de um único objeto; pré-visualize apenas o GUID registado depois dessas verificações:

Remove-ADObject -Identity $fsp.ObjectGUID -Server $dc -WhatIf

Esta pré-visualização não efetua qualquer eliminação. Não a transforme num pipeline sobre o contentor nem remova o próprio contentor. Mantenha juntas a decisão de limpeza, o plano de recuperação e a verificação final do acesso.

Como o EtcSec deteta este caso

A verificação FOREIGN_SECURITY_PRINCIPALS do EtcSec apresenta DomainInfo.ForeignSecurityPrincipalsCount. O método Detect() revisto inicializa a contagem a zero, copia o campo quando DomainInfo existe e devolve um resultado de gravidade Medium que contém essa contagem. Por isso, a ausência de DomainInfo produz zero. Os detalhes para uma contagem positiva acrescentam uma ressalva, não evidência por objeto ou uma classificação de SID.

O fornecedor LDAP efetua uma pesquisa paginada de subárvore sob CN=ForeignSecurityPrincipals,<baseDN>, utilizando (objectClass=foreignSecurityPrincipal). Pede apenas distinguishedName e atribui o número de entradas devolvidas quando a pesquisa é bem-sucedida. Um erro de pesquisa deixa o campo no seu valor inicial de zero. Este campo não disponibiliza um indicador de sucesso da recolha que distinga essa falha de um resultado vazio obtido com sucesso.

A verificação não disponibiliza SIDs individuais, memberOf, responsáveis, nomes resolvidos, conectividade da relação de confiança ou permissões efetivas. A sua contagem mistura objetos de representação well-known e referências externas reais. Não consegue identificar um objeto órfão, contar relações de confiança, provar exposição entre florestas ou estabelecer que zero significa um inventário sem problemas. A recolha e classificação independentes acima fornecem a evidência necessária para uma decisão. Este fluxo não inclui eliminação automática.

O texto explicativo do coletor também generaliza a criação de objetos de representação a referências em ACL. A fonte histórica da Microsoft utilizada aqui estabelece o caso de member; essa formulação mais ampla não é repetida como uma regra verificada. Trate o resultado como um convite a analisar os objetos subjacentes e as suas dependências, mantendo ou alterando apenas aquilo que a evidência sustenta.