Ao duplicar um template no ADCS, é comum surgirem dois OIDs na partição de configuração e um deles parecer “órfão”. Neste guia, explico por que isso acontece, quando é seguro removê‑lo e como adotar OIDs próprios sob o seu PEN com governança e compatibilidade.
Contexto e motivação
Organizações que usam Active Directory Certificate Services (ADCS) frequentemente duplicam templates para atender cenários de autenticação, assinatura de código, TLS interno ou S/MIME. Nesse processo, administradores percebem, via ADSI Edit ou ferramentas de inventário, que dois objetos relacionados a OID aparecem na partição de configuração. Um deles desaparece ao excluir o template recém‑criado; o outro permanece. Isso levanta três dúvidas práticas: “por que existem dois?”, “posso usar OIDs do meu Private Enterprise Number (PEN)?” e “é seguro apagar o OID que ficou?”.
Resumo rápido para decisão
| Aspecto | Resposta resumida |
|---|---|
| Por que existem dois objetos OID? | Ao duplicar um template, o AD cria: (A) um objeto associado ao template (mapeador do OID do template) e (B) um objeto de OID “genérico” sob o contêiner de OIDs (Enterprise OID), reutilizável por políticas e EKUs. O segundo pode permanecer para preservar referências e não é limpo automaticamente. |
| É seguro substituir o OID padrão por um PEN próprio? | Sim, é boa prática quando você cria novos OIDs (para templates, EKUs ou políticas internas). Siga a árvore do seu PEN, garanta compatibilidade com sistemas que consomem os certificados e mantenha uma governança rígida para evitar colisões. |
| O que fazer com o segundo OID “órfão”? | Investigue dependências (EKUs, políticas, certificados emitidos, NPS/NDES/serviços) antes de remover. Se não houver vínculos, a exclusão manual é aceitável, idealmente após backup/snapshot da partição de configuração e com plano de reversão. |
Entendendo onde os OIDs “moram” no AD
No AD, os elementos de PKI ficam na partição de configuração, em especial dentro de CN=Public Key Services,CN=Services, (ConfigurationNC). Simplificando:
- Templates de certificado residem em
CN=Certificate Templates,CN=Public Key Services,...e carregam, entre outros atributos, omsPKI-Cert-Template-OID, que identifica de forma única o template. - Objetos de OID de empresa residem em
CN=OID,CN=Public Key Services,...e representam OIDs reutilizáveis (inclusive para Application Policies/EKUs e políticas de emissão).
Essa separação explica por que você vê “dois objetos” quando duplica um template: um é o próprio template com seu OID; o outro é o objeto de OID empresarial correspondente no contêiner de OIDs.
O que acontece ao duplicar um template
- Você duplica um template existente (por exemplo, Kerberos Authentication) e salva como NEW_KerberosAuthentication.
- O ADCS atribui um novo valor para
msPKI-Cert-Template-OIDdesse template duplicado e registra (ou reaproveita) um objeto correspondente no contêinerCN=OID. - O objeto de OID empresarial recebe, tipicamente, o mesmo displayName do template no momento da criação, servindo como “âncora” para referências por EKUs/políticas que apontem para aquele OID.
Se você excluir o template, o objeto do template some. Já o objeto do OID empresarial pode ficar — e isso é desejado quando ainda existirem referências (por exemplo, certificados emitidos contendo aquele OID no EKU).
Por que o segundo OID permanece
O objeto de OID empresarial funciona como um catálogo corporativo de OIDs. Ele pode ser referenciado por:
- EKUs (Application Policies) usados por templates diferentes;
- Políticas de emissão ou de registro (RA);
- Serviços integrados (NPS, NDES/SCEP, proxies TLS internos), que verificam OIDs específicos;
- Ferramentas de terceiros (inspeção TLS, MDM, leitores de cartão), que validam OIDs durante a autenticação.
Como essas referências podem existir fora do escopo do template que você acabou de remover, o AD não elimina automaticamente o OID empresarial. Isso evita que certificados já emitidos “percam” a sua semântica.
Quando (e como) usar o seu PEN
Se a sua organização possui um PEN (Private Enterprise Number), usar OIDs sob esse PEN em novas definições é uma boa prática, pois:
- Garante unicidade global dos seus OIDs;
- Evita sobrecarga de OIDs “genéricos”/reservados;
- Facilita governança e auditoria interna.
Regras práticas:
- Não substitua EKUs padrão da indústria (por exemplo, Client Authentication, Server Authentication) quando o objetivo é interoperabilidade com software de mercado. Esses OIDs públicos devem permanecer.
- Crie OIDs sob o seu PEN para novos EKUs/políticas internas ou para novos templates com semântica proprietária (como autenticação baseada em atributos internos, carimbos de tempo internos, etc.).
- Evite “migrar” OIDs de templates amplamente implantados sem um plano de coexistência, para não invalidar workloads que já esperam o OID antigo.
Exemplo de árvore de OID sob um PEN corporativo
| Uso | Exemplo de arco | Observações |
|---|---|---|
| Templates de certificado | 1.3.6.1.4.1.<PEN>.1.x | x sequencial por família de template; documentar displayName e proprietário. |
| EKUs internos | 1.3.6.1.4.1.<PEN>.2.x | Separar EKUs de emissão e de uso final; mapear “friendly name” de cada OID. |
| Políticas de emissão | 1.3.6.1.4.1.<PEN>.3.x | Útil quando restrições de políticas fazem parte de auditorias. |
Passo a passo para adoção de OIDs próprios
- Desenhe a árvore de OIDs do seu PEN e publique um documento interno com propósito, dono e ciclo de vida de cada arco.
- Crie os objetos de OID no AD sob
CN=OID(com displayName e descrição claros). Isso facilita referência e evita “colisões de significado”. - Associe EKUs nos templates que precisarem de políticas/semânticas internas. Para interoperabilidade, mantenha também os EKUs padrão quando necessário.
- Implemente testes em todos os consumidores (NPS, IIS/HTTP.sys, aplicações, MDM, VPN, etc.).
- Documente o mapeamento OID ⇄ friendly name para equipes internas e fornecedores.
Investigando o “segundo OID” que ficou
Antes de remover qualquer objeto em CN=OID, siga um roteiro de triagem para descobrir dependências reais:
Checklist de investigação
- Mapeie o OID: anote o valor numérico (ex.:
1.3.6.1.4.1.99999.2.10) e o displayName. - Procure templates que usem esse OID: além de
msPKI-Cert-Template-OIDno próprio template, verifique se o OID aparece em EKUs do template. - Vasculhe serviços: NPS (RADIUS), NDES/SCEP, proxies TLS, serviços web, gateways VPN. Muitos validam EKUs/OIDs.
- Inspecione o banco da CA: certifique-se se há certificados emitidos recentemente que incluam esse OID.
- Converse com donos de aplicações: às vezes o OID foi pactuado com um time de app/segurança e ainda está ativo.
Comandos úteis em PowerShell
Dica: execute com privilégios adequados e em um host com RSAT (módulo ActiveDirectory) instalado.
$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$PKIBase = "CN=Public Key Services,CN=Services,$ConfigNC"
$TplBase = "CN=Certificate Templates,$PKIBase"
$OIDBase = "CN=OID,$PKIBase"
Listar templates e seus OIDs
Get-ADObject -LDAPFilter "(objectClass=pKICertificateTemplate)" \`
-SearchBase \$TplBase -Properties displayName,msPKI-Cert-Template-OID |
Select-Object displayName, @{n='TemplateOID';e={$\_.'msPKI-Cert-Template-OID'}} |
Sort-Object displayName
Listar OIDs empresariais
Get-ADObject -LDAPFilter "(objectClass=msPKI-Enterprise-Oid)" \`
-SearchBase \$OIDBase -Properties displayName,msPKI-OID,description |
Select-Object displayName, @{n='OID';e={$\_.'msPKI-OID'}}, description |
Sort-Object displayName
Procurar objetos que tenham um OID específico
\$TargetOID = "1.3.6.1.4.1.99999.2.10"
Get-ADObject -LDAPFilter "(|(msPKI-Cert-Template-OID=\$TargetOID)(msPKI-OID=\$TargetOID))" \`
-SearchBase \$PKIBase -Properties \* |
Select-Object name, objectClass, distinguishedName Interpretação: se o OID aparecer em EKUs de templates, políticas ou outros objetos, considere esse OID “em uso”.
Inspecionando a CA e certificados emitidos
Na CA, você pode usar certutil para localizar certificados que carregam determinado OID no EKU (ou filtrar por template). Alguns comandos práticos:
# Listar templates conhecidos pela CA
certutil -catemplates
Pesquisar por um template específico na base da CA
certutil -view -restrict "CertificateTemplate=NEW\_KerberosAuthentication"
Dump de um certificado (substitua pelo SerialNumber)
certutil -dump \ Se encontrar certificados recentes ou ativos que contenham o OID alvo em seus EKUs, não remova o OID empresarial correspondente ainda; planeje a transição.
Processo seguro para remoção de um OID empresarial
Se a investigação indicar ausência de dependências, siga um fluxo de baixo risco:
- Backup/snapshot: garanta System State ou snapshot da VM do DC (ou snapshots do AD via ferramentas aprovadas). Se a Lixeira do AD estiver habilitada, melhor ainda.
- Marque o objeto: antes de excluir, considere prefixar o displayName com
[DEPRECATED]e aguarde um ciclo (ex.: duas semanas) para observar se surge alguma reclamação. - Remova com PowerShell (após o período de observação):
$obj = Get-ADObject -LDAPFilter "(msPKI-OID=$TargetOID)" -SearchBase $OIDBase
if ($obj) {
Remove-ADObject -Identity $obj.DistinguishedName -Confirm:$false
}
Rollback: se necessário, restaure via Recycle Bin do AD ou a partir de backup/snapshot.
Boas práticas de governança de OIDs
- Inventário centralizado: mantenha uma planilha ou repositório com cada OID, dono, propósito, status (ativo/obsoleto), data e impacto.
- Nunca reutilize OIDs: um OID aposentado deve permanecer reservado para sempre; reaproveitar quebra a semântica de certificados antigos.
- Delegação controlada: somente um grupo restrito pode criar/atribuir OIDs e templates. Revise solicitações com um CAB (Change Advisory Board) ou processo de RFC interno.
- Nomes amigáveis consistentes: defina padrões de displayName e friendly name (ex.:
ORG UserAuth v2) e evite abreviações obscuras. - Ciclo de vida documentado: para cada OID, descreva criação, teste, produção, descontinuação e plano de migração.
Compatibilidade e testes
Introduzir um OID próprio pode afetar cadeias de validação. Antes de ir a produção:
- Testes de autenticação com NPS, VPN, proxies, gateways e controladores de domínio (para smart card logon e Kerberos, quando aplicável).
- Testes de cliente com navegadores, sistemas operacionais e bibliotecas criptográficas comuns (OpenSSL, Schannel, NSS), garantindo que o EKU/OID seja aceito.
- Compatibilidade móvel/MDM: perfis de certificação em iOS/Android podem exigir EKUs específicos. Inclua OIDs padrão além dos internos quando necessário.
Modelos de comunicação e documentação
Para evitar fricção entre times, inclua no seu repositório interno:
- Mapa OID ⇄ friendly name ⇄ sistema/aplicação que consome;
- Exemplos de CSR e OpenSSL config para desenvolvedores;
- Passos de diagnóstico (
certutil,openssl x509 -text) para suporte de primeiro nível; - Guia de rollback em caso de incidentes.
Erros comuns e como evitar
- Confundir EKU padrão com OID interno: não substitua OIDs do padrão IETF/CA/B se busca interoperabilidade.
- Excluir OID em uso por engano: sempre pesquise por referências (templates, CA, serviços) e use um período de observação com
[DEPRECATED]. - Reutilizar OID “livre”: um OID que já apareceu em produção nunca deve ser reaproveitado.
- Governança frouxa: sem um catálogo e um dono por OID, colisões e retrabalho são inevitáveis.
Exemplo de fluxo de criação de um novo EKU interno sob seu PEN
- Definir o propósito: “Autenticação de usuários em rede interna com MFA”.
- Alocar OID:
1.3.6.1.4.1.<PEN>.2.20. - Criar objeto em
CN=OIDcom nome amigável e descrição (time responsável, contato, data, ambientes). - Configurar template adicionando o novo EKU além dos EKUs padrão necessários.
- Homologar em piloto com NPS/VPN e aplicações críticas.
- Auditar após o corte para validar que apenas certificados com o novo EKU são aceitos onde esperado.
Snippet de automação para criar um OID empresarial
Exemplo ilustrativo de criação de um objeto de OID — ajuste nomes, OID e descrição conforme o seu padrão interno:
$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$OIDBase = "CN=OID,CN=Public Key Services,CN=Services,$ConfigNC"
\$NewOIDValue = "1.3.6.1.4.1.99999.2.20"
\$Display = "ORG UserAuth EKU"
\$Desc = "EKU interno para autenticação de usuários; Owner: Time PKI; Contato: [pki@org.exemplo](mailto:pki@org.exemplo)"
New-ADObject -Name \$Display ` -Type "msPKI-Enterprise-Oid"`
-Path \$OIDBase \`
-OtherAttributes @{
"displayName" = \$Display
"msPKI-OID" = \$NewOIDValue
"description" = \$Desc
} Observação: este exemplo cria o objeto de OID empresarial. A associação aos templates e a propagação para a CA devem ser feitas nos consoles apropriados e validadas com testes.
FAQ objetivo
Posso “editar” o OID de um template existente em massa?
O OID do template é a identidade lógica do próprio template. Para mudanças com compatibilidade, crie um novo template (com novo OID), migre consumidores e aposente o antigo.
É seguro apagar um OID empresarial sem verificar a CA?
Não. Sempre verifique a base da CA e os serviços consumidores. OIDs podem estar presentes em certificados ativos e políticas de acesso.
Preciso registrar friendly names no Windows?
Sim, friendly names consistentes ajudam na administração e troubleshooting. Padronize-os no AD e, quando aplicável, em hosts que exibem OIDs para operadores.
Conclusão
O “segundo OID” que permanece após a exclusão de um template não é um bug, mas um artefato de design do ADCS para permitir reutilização e preservar referências. Remova‑o apenas se não houver dependências ativas, preferencialmente após um período de observação e com backup/rollback planejados. Por outro lado, adotar OIDs sob o seu PEN é uma prática recomendada para novos EKUs/políticas/templates internos, desde que você garanta compatibilidade, documentação e governança de ponta a ponta.