Verificacao Server Core DC: identificar a opção instalada

O que é a Verificacao Server Core DC?

A verificação de Server Core nos DC consiste em determinar a opção de instalação de cada controlador de domínio a partir de evidências recolhidas nesse anfitrião. Comece por um inventário de DC e associe a cada entrada o tipo de instalação local, a edição do sistema operativo, a versão, o momento da recolha e o resultado da leitura. Uma designação no diretório ou uma captura de ecrã deixa uma lacuna nas evidências.

O problema imediato é operacional: uma equipa vê um lembrete sobre Server Core numa auditoria de AD e assume que tem uma lista de máquinas a reconstruir. Antes de aceitar essa lista, pergunte o que o collector observou efetivamente. Um lembrete para verificar uma opção de instalação é útil, mas não demonstra que um servidor específico utiliza Desktop Experience.

Mantenha o resultado desta análise separado da decisão de alteração. Uma opção de instalação verificada responde ao que está instalado hoje. O responsável ainda precisa de determinar que funções e ferramentas de administração o destino deve suportar, se uma reconstrução é adequada e como a alteração será validada.

Como funciona: separar o inventário do diretório das evidências do anfitrião

A Microsoft documenta Server Core e Server with Desktop Experience como opções de instalação. Core não inclui a interface de ambiente de trabalho padrão e suporta administração por linha de comandos ou remota. A comparação das opções de instalação abrange Windows Server 2016, 2019, 2022 e 2025.

O diretório e o anfitrião respondem a perguntas diferentes. Os atributos LDAP, como operatingSystem e operatingSystemVersion, ajudam a organizar um inventário. Na implementação do collector analisada para este artigo, não distinguem Core de Desktop Experience na mesma edição de Windows Server. Preserve esses valores como contexto; não transforme a ausência da subcadeia «Core» num veredito.

A página arquivada da Microsoft Determining Whether Server Core Is Running descreve a verificação de InstallationType em HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion: o valor Server Core identifica essa opção de instalação. A página também descreve GetProductInfo como o teste programático recomendado. As suas constantes históricas de produto não devem ser tratadas como um inventário universal das edições atuais.

Para esta análise, preserve o resultado do registo obtido diretamente de cada anfitrião. Não substitua o inventário do diretório por uma designação presumida. Relacione os dois conjuntos de evidências através da identidade do DC, para que um revisor possa identificar a máquina inspecionada e as máquinas cuja leitura continua por fazer.

Deteção: criar um registo de evidências por DC

Passo 1 — Fixar o inventário e o seu âmbito

Registe o domínio, o servidor de diretório consultado, o momento da recolha e as exclusões juntamente com a lista de DC. Reconcilie essa lista com o inventário operacional mantido pela equipa do diretório. Um anfitrião omitido não pode passar a «verificado» simplesmente por estar ausente dos dados de uma auditoria.

Utilize uma linha separada para cada DC esperado. Se a leitura do diretório falhar ou o inventário não puder ser reconciliado, preserve esse problema explicitamente. Evite uma percentagem de sucesso ou uma conclusão para todo o domínio enquanto a população avaliada for incerta.

Um registo de evidências útil inclui:

Estes são campos propostos para a análise, não uma afirmação de que a EtcSec recolhe todos eles. Guarde as evidências através do seu processo de administração estabelecido, com acesso adequado a registos de configuração de controladores de domínio.

Passo 2 — Ler o tipo de instalação no anfitrião

Utilize uma sessão local autorizada ou o seu mecanismo estabelecido de execução administrativa que efetue a leitura no DC pretendido. O PowerShell seguinte é um exemplo criado para o artigo, apenas de leitura, que implementa a verificação do registo documentada pela Microsoft. Não é um comando copiado do Learn e não foi executado para este artigo.

$observedAt = [DateTime]::UtcNow.ToString('o')
$hostName = $env:COMPUTERNAME
try {
    $cv = Get-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -ErrorAction Stop
    $os = Get-CimInstance -ClassName Win32_OperatingSystem -ErrorAction Stop
    $readOutcome = if ([string]::IsNullOrWhiteSpace($cv.InstallationType)) {
        'InstallationType missing'
    } else {
        'Read succeeded'
    }
    [pscustomobject]@{
        HostName = $hostName
        ObservedAtUtc = $observedAt
        InstallationType = $cv.InstallationType
        Edition = $os.Caption
        Version = $os.Version
        BuildNumber = $os.BuildNumber
        ReadOutcome = $readOutcome
        ReadError = $null
    }
} catch {
    [pscustomobject]@{
        HostName = $hostName
        ObservedAtUtc = $observedAt
        InstallationType = $null
        Edition = $null
        Version = $null
        BuildNumber = $null
        ReadOutcome = 'Read failed'
        ReadError = $_.Exception.Message
    }
}

Capture a saída e associe-a à linha do inventário. Verifique se o anfitrião indicado é o DC pretendido; executar uma consulta ao registo na estação de administração responde a uma pergunta diferente. Se não for possível sequer estabelecer a sessão, registe separadamente esse erro de transporte ou de acesso, porque este script local nunca foi executado.

O exemplo trata de forma conservadora uma leitura combinada sem sucesso. Se a consulta da identidade do SO falhar depois de a consulta ao registo ter sido bem-sucedida, devolve uma linha de falha em vez de uma observação completa. Preserve a saída de diagnóstico original ao investigar esses casos e repita a leitura em falta pela via aprovada.

Passo 3 — Interpretar os resultados sem eliminar os estados desconhecidos

Uma leitura bem-sucedida que devolva Server Core fornece a evidência descrita pela Microsoft. Preserve literalmente qualquer outra cadeia devolvida e esclareça o seu significado para esse anfitrião antes de decidir sobre a opção de instalação. Um valor em falta ou uma leitura falhada continua a ser desconhecido.

Não preencha manualmente células desconhecidas a partir de DC vizinhos, modelos de implementação ou da aparência recordada de uma sessão de início de sessão. Estes elementos podem orientar a investigação, mas o registo de evidências deve continuar a mostrar o que foi realmente obtido de cada anfitrião.

Correção: resolver dependências antes de planear uma reconstrução (Remediation)

Passo 1 — Colmatar primeiro as lacunas nas evidências

Atribua cada DC cuja leitura esteja por fazer a um responsável que possa obter as evidências do anfitrião. Mantenha visíveis o motivo da falha e a próxima ação de investigação. Corrija a via de recolha ou resolva o acesso através do processo normal de administração e depois repita a leitura.

Depois de determinar a opção de instalação de um anfitrião, registe a decisão separadamente: manter a opção atual, testar uma dependência ou planear uma substituição. Isto impede que um lembrete de auditoria se transforme numa instrução automática de reconstrução.

Passo 2 — Analisar as funções e ferramentas necessárias

O catálogo de funções e serviços de Server Core da Microsoft inclui Active Directory Domain Services (AD-Domain-Services) e DNS Server (DNS). A disponibilidade no catálogo não demonstra que uma função está instalada nem que todas as dependências de terceiros num determinado DC funcionam.

Peça ao responsável que enumere as tarefas de administração necessárias e as ferramentas de monitorização, cópia de segurança, recuperação e segurança. Para cada elemento, identifique como será utilizado no destino proposto e quem o testará. Um teste de aceitação útil é uma tarefa específica com saída preservada, como demonstrar o procedimento aprovado de cópia de segurança no ambiente de teste; «a ferramenta abre» é demasiado vago.

A documentação da App Compatibility Feature on Demand aplica-se a Windows Server 2019, 2022 e 2025. Adiciona componentes selecionados, incluindo MMC e File Explorer, a Core. Ver essas ferramentas é, portanto, insuficiente para identificar Desktop Experience. Este pacote não converte a opção de instalação.

Se esse pacote for uma dependência analisada, o Learn fornece exatamente este comando de instalação através do Windows Update:

Add-WindowsCapability -Online -Name "ServerCore.AppCompatibility~~~~0.0.1.0"

Este é um comando de alteração documentado, não um comando de deteção; não foi executado aqui. A Microsoft exige acesso de administrador, um reinício após a instalação e atualizações posteriores do sistema operativo. Para uma origem ISO, utilize o método documentado e suportes que correspondam à versão de Windows Server instalada.

Passo 3 — Planear uma mudança da opção de instalação como uma instalação limpa

Para as versões abrangidas pela página das opções de instalação, a Microsoft exige uma instalação limpa para mudar entre Core e Desktop Experience após a instalação. Remover um componente gráfico não é um procedimento de conversão suportado.

Se a substituição for a ação escolhida, relacione esta análise de evidências com o procedimento sobre o ciclo de suporte do Windows Server e a atualização de controladores de domínio. Esse artigo abrange o suporte, os pré-requisitos e o planeamento da transição de DC; não fornece prova local da opção de instalação existente.

Inclua no plano as evidências do DC original, a opção de destino pretendida, os resultados dos testes de dependências e o responsável pela alteração. Após a substituição, recolha um novo registo do anfitrião e reconcilie novamente o inventário. Preserve o registo anterior como histórico, para que o revisor possa ver que observação sustenta cada decisão.

Contexto ANSSI: utilizar a recomendação tal como está escrita

A ANSSI-PA-099 identifica a recomendação como R19+, com o título «Utiliser Windows en « Server Core » sur le périmètre du Tier 0» na página impressa 36. O guia ANSSI expressa uma preferência por Core nos DC para reduzir a superfície de ataque e estende a recomendação aos servidores Windows do Tier 0, em particular aos que comunicam com recursos menos sensíveis.

Utilize o contexto de administração segura do guia ANSSI para Active Directory para enquadrar a decisão no modelo mais amplo de administração. Essa visão geral não verifica InstallationType em anfitriões individuais. Nem uma designação LDAP nem o lembrete descrito abaixo estabelece a conformidade com a recomendação.

Como a EtcSec deteta isto

A verificação do etc-collector analisada é ANSSI_R19_SERVER_CORE_NOT_USED, no commit afca1b9f7bba6f076d6a6493371486071001452b. O seu identificador não deve ser interpretado como um resultado medido de «Core não utilizado».

Detect() não devolve qualquer constatação quando a sua entrada de DC está vazia. Caso contrário, emite um lembrete Info, com Count igual ao número de DC nessa entrada. Essa contagem é a população que requer verificação no anfitrião, não uma contagem de instalações de Desktop Experience confirmadas.

O fornecedor LDAP lê objetos de computador e mapeia operatingSystem e operatingSystemVersion. O motor de auditoria deriva os DC dos objetos de computador recolhidos após as exclusões aplicáveis. Esta via não lê InstallationType no registo do anfitrião; as cadeias LDAP não distinguem Core de Desktop Experience.

Utilize o lembrete para iniciar a análise por DC, associar evidências do anfitrião e documentar a decisão resultante. Não o apresente como um veredito sobre a GUI, uma constatação de não conformidade ou prova de que é necessária uma reconstrução.

Análise antes de encerrar a verificação

Forneça ao revisor o inventário reconciliado, cada leitura do anfitrião ou erro, a interpretação dos valores devolvidos e as decisões sobre dependências. Confirme que o registo final inclui as máquinas cuja leitura estava inicialmente por fazer ou enumera explicitamente as que continuam por resolver.

A análise fica concluída quando o seu âmbito e as evidências sustentam as conclusões indicadas ao nível do anfitrião. Mantenha a verificação da opção de instalação, a compatibilidade operacional e a avaliação ANSSI mais ampla como decisões documentadas separadamente.