redircmp redirusr contentores predefinidos politica de grupo: guia AD

O que são os contentores predefinidos no Active Directory?

A questão prática por trás de redircmp redirusr contentores predefinidos politica de grupo é onde ficam as novas identidades e se essa localização pertence à estrutura de políticas pretendida. O Active Directory cria CN=Computers e CN=Users quando o domínio é instalado. São contentores, em vez de unidades organizacionais. A orientação da Microsoft sobre redirecionamento de contentores explica a sua função predefinida, enquanto a visão geral da Política de Grupo identifica uma OU como o nível mais baixo do AD ao qual se pode atribuir uma Política de Grupo.

Não é possível ligar uma GPO diretamente a estes contentores predefinidos. Isso não significa que os seus computadores e utilizadores não recebam qualquer Política de Grupo: as GPOs ligadas ao site e ao domínio podem continuar a aplicar-se, e a política local continua a ser relevante. A lacuna é mais específica. Um objeto em CN=Computers fica fora da subárvore de uma política ligada apenas à OU das estações de trabalho ou dos servidores. A referência de Redircmp da Microsoft confirma a ausência de uma ligação direta de Política de Grupo ao contentor predefinido. As regras de âmbito de site, domínio e OU estão documentadas na visão geral da Política de Grupo citada acima.

Este guia separa quatro questões: onde os objetos se encontram atualmente, onde a criação predefinida os colocará no futuro, quais as políticas que realmente chegam ao cliente e quais as contas de computador que precisam de uma revisão do aprovisionamento. Um resultado relativo ao contentor predefinido responde à primeira questão. O redirecionamento trata da segunda. Nenhum dos dois estabelece o estado do LAPS no cliente nem a segurança de uma conta de máquina preparada antecipadamente.

Como funciona: o destino e o âmbito da política são distintos

A criação predefinida segue uma referência no diretório

A Microsoft documenta os destinos predefinidos no atributo wellKnownObjects do domínio. As APIs de criação mais antigas consultam estas referências para utilizadores, grupos e computadores. Os utilitários de redirecionamento alteram as referências para OUs escolhidas pelo administrador; não transformam os contentores originais em OUs. Os novos objetos criados através dos caminhos predefinidos afetados passam então a utilizar o novo destino. KB324949 descreve as referências e as operações que delas dependem.

Um fluxo de adesão ao domínio também pode indicar um destino explicitamente. A referência de netdom join documenta /ou e indica que a criação da conta utiliza o destino predefinido de computadores do domínio quando essa opção é omitida. Numa instalação normal sem redirecionamento, esse destino é CN=Computers; após o redirecionamento, pode ser a OU designada. Uma conta existente reutilizada para uma adesão constitui outro caso. Por isso, evite assumir que cada adesão cria necessariamente um novo objeto no contentor predefinido.

Para os utilizadores, redirusr afeta a localização de criação predefinida de utilizadores, grupos e contas de utilizador de confiança criados através das APIs documentadas. A colocação de um grupo não significa que o próprio grupo processe a configuração de utilizador como um utilizador com sessão iniciada. Mantenha o inventário de contas e o processamento de políticas separados e preserve as contas predefinidas, salvo se uma alteração analisada separadamente exigir o contrário. S1 descreve o conjunto mais amplo de objetos afetados pelo destino Users.

A colocação numa OU cria um caminho elegível, não um controlo concluído

O âmbito da Política de Grupo segue as ligações em sites, domínios e OUs, incluindo a hierarquia relevante de OUs superiores. Mover um computador para uma OU prevista pode colocá-lo sob essa hierarquia, mas continua a ser necessário validar o processamento e as definições pretendidas. A visão geral da Microsoft descreve o âmbito baseado na localização e o processamento do lado do cliente.

O nosso guia de filtragem de segurança de GPO aborda a camada seguinte: âmbito da ligação, Read para o computador, Apply para o utilizador e a distinção entre conceder acesso para obter a política e alargar o público a que ela se aplica. A sua tese é que a localização correta e uma política ligada não são suficientes sem as permissões e as condições de processamento necessárias. Faça essa revisão depois de corrigir a colocação.

O LAPS acrescenta os seus próprios requisitos de implementação. O procedimento da Microsoft para Windows LAPS com suporte em AD separa a permissão de escrita do dispositivo, a permissão de obtenção da palavra-passe, a política do dispositivo e a verificação das atualizações no diretório. Assim, um computador fora de uma OU que seja a única fonte da sua política LAPS pode ter um problema de cobertura; um computador que receba uma política equivalente por outra via suportada pode não o ter.

O guia relacionado sobre lacunas de cobertura LAPS analisa a implementação parcial, o armazenamento legado, os direitos excessivos de recuperação e as provas necessárias para validar a rotação. Fornece a revisão seguinte quando a colocação revela uma possível lacuna. Contar os computadores em CN=Computers não mede os computadores sem LAPS.

Medir a colocação antes de alterar os destinos predefinidos

1. Inventariar os computadores no contentor predefinido

Utilize um domínio definido e registe a base de pesquisa, a hora da recolha, o estado de ativação e os identificadores dos objetos. O exemplo seguinte para o leitor adapta os parâmetros documentados Filter, SearchBase, SearchScope e Properties de Get-ADComputer. Os nomes de domínio e de objetos ao longo deste guia são exemplos fictícios.

Get-ADComputer -Filter * -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Properties Enabled,userAccountControl

O objetivo é enumerar os objetos diretamente subordinados para uma revisão da colocação. Esta consulta inclui contas desativadas, enquanto o detetor de colocação EtcSec analisado as exclui. Mantenha essas populações separadas ao comparar resultados. Um inventário administrativo e a contagem de um detetor não têm de ser idênticos, porque os seus predicados diferem.

A contagem de um contentor mede a colocação no diretório, não a cobertura de proteção. Decida quais os objetos que pertencem à produção, quais são contas de preparação aprovadas e quais precisam de investigação. Registe, para cada objeto, o destino proposto e o proprietário responsável. São decisões de revisão; o comando fornece dados do diretório, em vez de uma avaliação da proteção dos dispositivos.

2. Inventariar os utilizadores sem tratar o contentor como uma única classe de contas

O exemplo seguinte substitui o contentor Users predefinido no padrão documentado de pesquisa de contentores e solicita o estado de ativação através de Properties. Get-ADUser documenta ambos os parâmetros:

Get-ADUser -Filter * -SearchBase 'CN=Users,DC=contoso,DC=com' -Properties Enabled

Isto obtém utilizadores, em vez de um inventário completo de todos os grupos e objetos especiais no contentor. A orientação de redirecionamento da Microsoft aborda especificamente os grupos predefinidos e as contas de utilizador de confiança. Antes da migração, distinga os utilizadores comuns das contas incorporadas ou dependentes de aplicações e determine quais os objetos que devem permanecer no local.

Analise a origem e o destino em conjunto. Um utilizador movido para outra OU pode entrar numa hierarquia diferente de políticas de utilizador, tal como um computador pode entrar numa hierarquia diferente de políticas de computador. Utilize o modelo de âmbito da Política de Grupo para identificar a alteração esperada antes de mover o objeto, em vez de considerar uma vista mais organizada do diretório como critério de conclusão.

3. Rever separadamente o sinal de aprovisionamento da conta de máquina

Um computador pode estar preparado numa OU adequada e continuar a precisar de revisão. Inversamente, um computador ativo no contentor predefinido pode não corresponder ao sinal de preparação. Para obter o atributo subjacente, este exemplo utiliza o parâmetro documentado Properties de Get-ADComputer:

Get-ADComputer -Filter * -Properties userAccountControl

A referência de UserAccountControl da Microsoft atribui a PASSWD_NOTREQD o valor 0x20 e a WORKSTATION_TRUST_ACCOUNT o valor 0x1000. O collector combina-os em 0x1020, decimal 4128, e testa se ambos os bits estão presentes. O predicado exato é explicado abaixo; não o substitua por um teste de igualdade contra todo o atributo.

Para as contas correspondentes, pergunte quem criou o objeto, que pedido de aprovisionamento suporta, se a máquina pretendida já aderiu ao domínio e que provas independentes de atividade existem. Defina um período local de revisão com o proprietário da conta. O detetor não fornece um limiar de idade nem um histórico de adesão verificado, pelo que nenhum deles deve constar de um suposto resultado do detetor.

Deteção: correlacionar sinais do diretório com resultados do cliente

Um objeto mal colocado é um candidato a uma revisão do âmbito

Trate a colocação como um sinal para investigar a relação de políticas pretendida. Registe as GPOs de referência esperadas para o computador, as localizações das suas ligações e os resultados reais do cliente. A documentação de gpresult define os relatórios de Conjunto de Políticas Resultante e as opções de âmbito de computador e de resumo utilizadas aqui:

gpresult /scope computer /r

Execute a verificação documentada para o leitor no computador em causa, com o acesso adequado. Compare as GPOs aplicadas com a referência esperada e depois verifique as definições relevantes. Um relatório que mostra a aplicação de políticas é uma prova diferente de uma cópia de segurança LAPS bem-sucedida ou do estado efetivo de uma definição de auditoria. Este artigo não afirma apresentar resultados de um domínio real.

Para Windows LAPS nativo com suporte em AD, o procedimento de implementação da Microsoft identifica o evento 10018 como prova de que uma nova palavra-passe foi atualizada com êxito no AD. Utilize-o como verificação separada do resultado quando essa implementação se aplicar. A ausência do evento exige uma investigação do momento e dos registos disponíveis; não é uma prova deduzida do DN do objeto.

As palavras-passe predefinidas históricas exigem contexto de versão

A criação antecipada pode ser um fluxo legítimo. A orientação da Microsoft sobre permissões de adesão ao domínio descreve um administrador a criar uma conta de computador e outra identidade autorizada a reutilizá-la. Uma conta preparada merece gestão do ciclo de vida, mas a preparação, por si só, não estabelece um comprometimento.

Existe um risco histórico distinto. A referência de NetProvisionComputerAccount documenta uma opção explícita que utiliza o nome da máquina em minúsculas como palavra-passe inicial e recomenda evitar essa opção sempre que possível. Isto descreve um modo específico de aprovisionamento. A máscara UAC não lê o segredo e não pode estabelecer que a opção foi utilizada, que uma palavra-passe está vazia ou é previsível, ou que a autenticação teve êxito.

A versão importa. As alterações do Windows Server 2025 documentadas pela Microsoft descrevem palavras-passe iniciais de contas de computador geradas aleatoriamente, controlos que rejeitam valores predefinidos derivados do nome e o facto de ADUC/ADAC já não permitirem a criação de contas anteriores ao Windows 2000. A política documentada é Domain controller: Refuse setting default machine account password. Verifique as versões dos controladores de domínio, as ferramentas de criação e esta política antes de aplicar o modelo histórico às contas atuais. Uma identidade abandonada continua a precisar de um proprietário e de uma decisão de ciclo de vida, mesmo que o seu segredo inicial fosse aleatório.

Correção: redirecionar a criação futura e migrar os objetos existentes (Remediation)

1. Conceber as OUs de destino e as suas responsabilidades

Escolha as OUs de destino de acordo com os requisitos de administração e de políticas. Decida se a criação predefinida deve entrar numa OU de preparação ou na hierarquia final de produção e documente quem conclui a transição. Uma OU chamada “Staging” só é útil quando a política pretendida e a equipa responsável são claras. A visão geral da Política de Grupo aborda o equilíbrio entre os requisitos de delegação e de políticas.

Os comandos seguintes adaptam o exemplo 1 de New-ADOrganizationalUnit, substituindo dois nomes de destino e o domínio fictício. O exemplo documentado cria uma OU com a proteção contra eliminação acidental implicitamente ativada. Cada operação é mostrada separadamente:

New-ADOrganizationalUnit -Name 'MyComputers' -Path 'DC=contoso,DC=com'

New-ADOrganizationalUnit -Name 'MyUsers' -Path 'DC=contoso,DC=com'

Prepare as políticas e a delegação pretendidas antes de utilizar estas OUs como destinos predefinidos. Criar a OU é uma operação de gestão de objetos; não liga uma GPO, não autoriza o aprovisionamento nem estabelece que um dispositivo processou uma política de referência.

2. Verificar os pré-requisitos do redirecionamento

KB324949 exige um nível funcional de domínio Windows Server 2003 ou superior, uma OU de destino existente, credenciais de Administrador de Domínio e um PDC acessível. Verifique a configuração real do domínio em vez de deduzir o nível funcional a partir do sistema operativo de um único servidor.

A página mais antiga de Redircmp enumera versões históricas de níveis funcionais. Utilize o requisito “2003 ou superior” do KB atual para este procedimento. A referência de Redircmp também exige uma linha de comandos com privilégios elevados. Elevar o nível funcional do domínio, se necessário, é uma decisão de compatibilidade separada; não deve ser apresentada como um passo secundário num artigo sobre colocação de objetos.

3. Alterar os destinos predefinidos de computadores e utilizadores independentemente

Os dois comandos seguintes reproduzem os exemplos da Microsoft em S1, omitindo o prefixo da linha de comandos. Cada comando altera um destino predefinido distinto:

redircmp ou=mycomputers,DC=contoso,dc=com

redirusr ou=myusers,DC=contoso,dc=com

A sintaxe genérica documentada é redircmp container-dn e c:\windows\system32\redirusr container-dn. O argumento é o distinguished name da OU de destino. Substitua-o pelo destino aprovado; um comando bem-sucedido trata da criação futura através dos caminhos predefinidos afetados.

Nenhum dos utilitários move os objetos existentes. Trate a colocação futura e a colocação existente como tarefas separadas. O aprovisionamento com OU explícita e a reutilização de contas também precisam da sua própria validação, em vez de serem deduzidos do novo destino predefinido.

4. Migrar objetos existentes selecionados com uma revisão das políticas

Avalie as dependências de aplicações, a finalidade da conta e a alteração esperada de políticas antes de selecionar cada objeto. O comando seguinte adapta a sintaxe documentada de Identity e TargetPath de Move-ADObject a um computador existente fictício:

Move-ADObject -Identity 'CN=PC01,CN=Computers,DC=contoso,DC=com' -TargetPath 'OU=MyComputers,DC=contoso,DC=com'

Selecione objetos reais através de um inventário revisto. Não utilize uma movimentação em massa indiscriminada de tudo o que existe em CN=Users ou CN=Computers. O KB de redirecionamento aborda a compatibilidade com versões anteriores e as contas predefinidas; a visão geral da Política de Grupo explica a herança que torna uma mudança de destino operacionalmente significativa.

Após a movimentação, confirme a nova localização do objeto e repita a revisão de políticas no cliente. Conclua a tarefa de colocação com provas do diretório e resolva qualquer lacuna de proteção com provas dessa proteção. São verificações relacionadas com critérios de conclusão diferentes.

5. Delegar a criação, a reutilização e a gestão de políticas de forma deliberada

A orientação da Microsoft sobre Delegação de Controlo separa tarefas como aderir computadores ao domínio, gerir utilizadores e gerir ligações GPO. Delegue as tarefas necessárias no âmbito adequado. Alterar um destino predefinido não concede à identidade que efetua a adesão permissão para criar ou reutilizar contas nesse local.

Para contas de computador reutilizadas, reveja o proprietário e as permissões necessárias à luz do procedimento de permissões de adesão ao domínio. Diagnostique uma adesão falhada de acordo com esses requisitos. Não alargue a pertença a grupos administrativos nem contorne verificações de propriedade apenas para fazer funcionar um fluxo acabado de redirecionar.

Para Windows LAPS nativo com suporte em AD, o procedimento de implementação documenta a permissão de autoatualização do dispositivo. Este exemplo substitui a OU de computadores aprovada nesse comando:

Set-LapsADComputerSelfPermission -Identity 'OU=MyComputers,DC=contoso,DC=com'

Isto não configura a política LAPS nem estabelece direitos de obtenção de palavras-passe. Valide separadamente a política pretendida e uma atualização bem-sucedida do cliente. Reveja também a população aprovada para recuperação; colocar um computador no âmbito da política não resolve o acesso excessivo à recuperação.

6. Rever as contas preparadas e testar os fluxos futuros

Para cada candidato de preparação, mantenha a finalidade de negócio, o proprietário, a ferramenta de aprovisionamento e as provas que sustentam a utilização continuada. Determine se a conta deve concluir o aprovisionamento, permanecer num processo de preparação aprovado ou entrar no procedimento de retirada de serviço da organização. Não se deduz da máscara UAC qualquer limiar universal de idade nem regra de eliminação automática.

Após a correção, teste um fluxo autorizado de nova conta que utilize o caminho predefinido e um fluxo que reutilize uma conta previamente criada. Verifique o destino resultante, as permissões, a aplicação esperada de GPOs e os resultados dos serviços aplicáveis. As permissões de adesão e as regras de destino de netdom da Microsoft explicam por que estes fluxos devem ser considerados separadamente.

Todos os comandos deste guia são exemplos documentados para o leitor ou adaptações explicitamente identificadas. Não foram executados contra um domínio AD para este artigo e não constituem prova de redirecionamento, migração ou rotação bem-sucedidos.

Como o EtcSec deteta este problema

As descrições seguintes refletem as implementações Detect() revistas no commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c do etc-collector. Os caminhos abaixo são relativos a public/internal/audit/detectors/.

COMPUTER_WRONG_OU, em ad/computers/organization/wrong-ou.go:35, ignora os computadores desativados, converte o DN para minúsculas e procura ,cn=computers,dc= nas linhas 39–49. Indica gravidade Low. Trata-se de um teste de subcadeia, em vez de uma comparação analisada do objeto superior com uma OU de destino configurada. Não inventaria a aplicação efetiva de GPOs nem estabelece a ausência de LAPS, de medidas de segurança ou de auditoria.

COMPUTER_PRE_CREATED, em ad/computers/status/pre-created.go:35, testa UserAccountControl & 0x1020 == 0x1020 nas linhas 38–41. São permitidos bits adicionais, incluindo o estado desativado. O seu resultado Medium não inclui condição de DN, limiar de idade, teste de histórico de início de sessão nem inspeção do valor do segredo. O nome do resultado identifica um sinal para revisão da preparação; o predicado não prova que o computador nunca aderiu ao domínio.

Um controlo adjacente, SERVER_NO_ADMIN_GROUP, foi revisto, mas não está associado a este artigo como etiqueta. Em ad/computers/organization/server-no-admin-group.go:43, seleciona computadores ativados classificados heuristicamente como servidores e verifica a cobertura através de ligações ativadas a dados de Restricted Groups analisados que contenham uma pertença não vazia a Administrators. As suas funções auxiliares estão nas linhas 102–186. Não deteta especificamente a presença em CN=Computers, não calcula a filtragem efetiva nem inspeciona a pertença local real do servidor. Sem dados de políticas GPO fornecidos, uma contagem zero não estabelece conformidade.

Utilize estes resultados para escolher o próximo passo de validação. Corrija a colocação, verifique o aprovisionamento futuro, estabeleça a proteção real do cliente e resolva a propriedade das contas preparadas separadamente. Um predicado de diretório que deixe de ser satisfeito é uma prova útil para esse predicado; uma correção operacional bem-sucedida exige as provas dos resultados correspondentes.