Windows
Implante certificados em dispositivos Windows via SCEP no Intune usando o SCEPman.
O artigo a seguir descreve a implantação de certificados de dispositivo e/ou usuário para dispositivos Windows. A implantação do Certificado Raiz do SCEPman é obrigatória. Depois, você pode escolher entre implantar apenas o certificado de dispositivo, de usuário ou mesmo ambos os tipos de certificado.
Certificado Raiz
A base para implantar certificados SCEP é confiar no certificado raiz do SCEPman. Portanto, você deve baixar o certificado CA Root e implantá-lo como um certificado Confiável perfil via Microsoft Intune:
Observe que você precisa usar o mesmo grupo para atribuir o certificado Confiável e o perfil SCEP. Caso contrário, a implantação pelo Intune pode falhar.
Certificados de Dispositivo
Formato do nome do sujeito: CN={{DeviceName}} ou CN={{DeviceId}} ou CN={{AAD_Device_ID}}
Recomendado: Use {{DeviceName}}para o RDN CN para ter um nome significativo do certificado no dispositivo ou ao procurar o certificado.
Opcional: Se configurado para CN={{DeviceId}} ou CN={{AAD_Device_ID}}, o SCEPman usa o campo CN do nome do sujeito para identificar o dispositivo e como semente para a geração do número de série do certificado. O Microsoft Entra ID (Azure AD) e o Intune oferecem dois IDs diferentes:
{{DeviceId}}: Este ID é gerado e usado pelo Intune. (requer SCEPman 2.0 ou superior e AppConfig:IntuneValidation:DeviceDirectory a ser definido para Intune ou AADAndIntune){{AAD_Device_ID}}: Este ID é gerado e usado pelo Microsoft Entra ID (Azure AD).
Caso nem CN={{DeviceId}} nem CN={{AAD_Device_ID}} sejam usados para o campo CN (por exemplo CN={{DeviceName}}), o SCEPman identificará o dispositivo com base no ID do Dispositivo do Intune ((URI)Valor: IntuneDeviceId://{{DeviceId}}) fornecido no nome alternativo do sujeito (SAN).
Importante: A escolha do campo CN afeta o comportamento automático de revogação de certificados emitidos para seus dispositivos gerenciados pelo Intune.
Você pode adicionar outros RDNs, se necessário (por exemplo: CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}). As variáveis suportadas estão listadas na documentação da Microsoft.
Nome alternativo do sujeito: (URI)Valor: IntuneDeviceId://{{DeviceId}}
O campo URI é recomendado pela Microsoft para soluções NAC identificarem os dispositivos com base no ID do Dispositivo do Intune. O valor deve ser:
O campo URI é obrigatório caso nem CN={{DeviceId}} nem CN={{AAD_Device_ID}} seja usado no campo Formato do nome do sujeito .
Outros valores SAN como DNS podem ser adicionados, se necessário.
Período de validade do certificado: 1 ano
A quantidade de tempo restante antes do certificado expirar. O padrão é definido em um ano.
O SCEPman limita a validade do certificado ao máximo configurado na configuração AppConfig:ValidityPeriodDays, mas caso contrário usa a validade configurada na solicitação.
Provedor de armazenamento de chave (KSP): Inscrever no KSP Trusted Platform Module (TPM), caso contrário falhar
Esta configuração determina o local de armazenamento da chave privada para os certificados de usuário final. O armazenamento no TPM é mais seguro do que o armazenamento em software porque o TPM fornece uma camada adicional de segurança para evitar o roubo da chave.
Observação: Existe um bug em algumas versões antigas de firmware de TPM que invalida algumas assinaturas criadas com uma chave privada suportada pelo TPM. Nesses casos, o certificado não pode ser usado para autenticação EAP, como é comum para conexões Wi-Fi e VPN. Além disso, isso pode quebrar seu processo de integração Autopilot.
As versões de firmware TPM afetadas incluem:
STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100, 73.20.17568.6684
Intel: 11.8.50.3399, 2.0.0.2060
Infineon: 7.63.3353.0
IFX: Versão 3.19 / Especificação 1.2
IFX versão 7.63.3353.0 especificação 2.0
Se você usar TPM com esse firmware, atualize seu firmware para uma versão mais recente ou selecione "Software KSP" como provedor de armazenamento de chave.
Atualização: Você pode contornar o bug do TPM removendo os algoritmos de assinatura RSA-PSS - que estão causando o problema - do registro; para mais informações, verifique o artigo de Richard Hicks e Microsoft Q&A
Uso da chave: Assinatura digital e Ciframento de chave
Por favor, ative ambas as ações criptográficas.
O SCEPman automaticamente define o Uso da chave para Assinatura digital e Ciframento de chave e substitui a configuração aqui, a menos que a configuração AppConfig:UseRequestedKeyUsages esteja definida para true.
Certificado Raiz: Perfil da etapa anterior (Perfil do certificado Raiz)
Por favor, selecione o perfil do Intune de #Certificado Raiz. Se você estiver usando uma CA Intermediária, você deve selecionar o perfil de certificado Confiável para a CA Intermediária, não para a CA Raiz!
Uso estendido da chave: Autenticação de Cliente, 1.3.6.1.5.5.7.3.2
Por favor, escolha Autenticação de Cliente (1.3.6.1.5.5.7.3.2) em Valores pré-definidos. Os outros campos serão preenchidos automaticamente.
Limite de renovação (%): 20
Este valor define quando o dispositivo está autorizado a renovar seu certificado (com base no tempo de vida restante de um certificado existente). Por favor, leia a nota em Período de validade do certificado e selecione um valor adequado que permita ao dispositivo renovar o certificado por um longo período. Um valor de 20% permitiria que o dispositivo com um certificado válido por 1 ano começasse a renovação 73 dias antes do vencimento.
URLs do servidor SCEP: Abra o portal SCEPman e copie a URL de Intune MDM
Exemplo
Exemplo
Certificados de Usuário
Por favor, siga as instruções de #Certificados de dispositivo e preste atenção às seguintes diferenças:
Formato do nome do sujeito: CN={{UserName}},E={{EmailAddress}}
Você pode definir RDNs com base em suas necessidades. As variáveis suportadas estão listadas na documentação da Microsoft. Recomendamos incluir o nome de usuário (por exemplo: janedoe) e o endereço de e-mail (por exemplo: [email protected]) como configuração básica.
Nome alternativo do sujeito: (UPN)Valor: {{UserPrincipalName}}
Você deve adicionar o nome principal do usuário como Nome alternativo do sujeito. Adicione '{{UserPrincipalName}}' como Nome Alternativo do Sujeito do tipo Nome principal do usuário (UPN). Isso garante que o SCEPman possa vincular certificados a objetos de usuário no AAD. A configuração para 'Formato do nome do sujeito' é livremente selecionável.
Outros valores SAN, como um endereço de Email, podem ser adicionados se necessário.
Com base no feedback dos clientes, parece que alguns clientes VPN (por exemplo, Azure VPN Client for Virtual WAN) não conseguem descobrir o certificado de usuário quando ele está armazenado no TPM. Tente registrá-lo no KSP de software em vez disso.
Exemplo
Certificado de Assinatura Digital do Usuário
Você pode usar o SCEPman para assinaturas digitais transacionais, ou seja, para assinatura S/MIME no Microsoft Outlook. Se você planeja usar os certificados para assinatura de mensagens, precisa adicionar os usos estendidos de chave correspondentes na configuração do perfil do Intune.
Não use o SCEPman para criptografia de e-mail ou seja, para criptografia de e-mail S/MIME no Microsoft Outlook (sem uma tecnologia separada para gerenciamento de chaves). A natureza do protocolo SCEP não inclui um mecanismo para backup ou arquivamento do material da chave privada. Se você usasse SCEP para criptografia de e-mail, pode perder as chaves para decifrar as mensagens mais tarde.
AppConfig:UseRequestedKeyUsagesdefinir paratrueAppConfig:ValidityPeriodDaysdefinir para365(um valor máximo de 1825 - 5 anos é possível)
Para implantar certificados de usuário usados para Assinaturas Digitais por favor, siga as instruções de #Certificados de usuário e observe as seguintes diferenças e notas:
Nome alternativo do sujeito
(obrigatório) Nome principal do usuário (UPN):
{{UserPrincipalName}}(obrigatório) Endereço de email:
{{EmailAddress}}
Ao implantar um certificado de assinatura digital, você deve adicionar o UPN e o endereço de e-mail.
Uso estendido da chave: Email Seguro (1.3.6.1.5.5.7.3.4)
Por favor, escolha Email Seguro (1.3.6.1.5.5.7.3.4) em Valores pré-definidos. Os outros campos serão preenchidos automaticamente.
Limite de renovação (%): 50
Recomendamos definir o Limite de Renovação (%) para um valor que garanta que os certificados sejam renovados pelo menos 6 meses antes da expiração ao emitir certificados de assinatura S/MIME. Isso porque e-mails assinados com certificados expirados aparecem com assinaturas inválidas no Outlook, o que confunde os usuários. Ter um novo certificado muito antes de o antigo expirar garante que apenas e-mails mais antigos mostrem esse comportamento, que os usuários têm menos probabilidade de consultar. Por exemplo, se seus certificados de assinatura são válidos por um ano, você deve definir o Limite de Renovação para pelo menos 50%.
Exemplo
Após uma sincronização de perfil bem-sucedida, você deverá ver o certificado de usuário para Finalidades Pretendidas Email Seguro
O certificado estará disponível para uso em Assinatura Digital em, por exemplo, Outlook. Abaixo está um exemplo do uso
Ativar Assinaturas S/MIME no Microsoft Outlook
O recurso S/MIME não está disponível para o cliente Outlook mais recente. Mais informações aqui.
Depois de implantar certificados de assinatura S/MIME em suas máquinas cliente, você deve configurar o Outlook para usar esses certificados antes de enviar e-mails assinados. Você pode fazer isso manualmente ou usar nosso Script PowerShell para configurar o Outlook.
Ativar Assinaturas S/MIME no Outlook na Web
Você pode assinar e-mails com S/MIME no Outlook na Web usando certificados da sua máquina Windows local. Você precisa habilitar isso com o seguinte comando:
Consulte https://learn.microsoft.com/en-us/powershell/module/exchange/set-smimeconfig para mais detalhes.
Last updated
Was this helpful?