Windows
Implementar certificados em dispositivos Windows via SCEP no Intune usando o SCEPman.
O artigo a seguir descreve a implementação de certificados de dispositivo e/ou de utilizador para dispositivos Windows. A implementação do SCEPman Root Certificate é obrigatória. Depois disso, pode escolher entre implementar apenas o certificado de dispositivo, de utilizador ou até ambos os tipos de certificado.
Root Certificate
A base para implementar certificados SCEP é confiar no certificado raiz do SCEPman. Por isso, tem de descarregar o certificado CA Root e implementá-lo como um certificado confiável perfil via Microsoft Intune:
Tenha em atenção que tem de usar o mesmo grupo para atribuir o certificado confiável e o perfil SCEP. Caso contrário, a implementação do Intune poderá falhar.
Certificados de dispositivo
Formato do nome do assunto: CN={{DeviceName}} ou CN={{DeviceId}} ou CN={{AAD_Device_ID}}
Recomendado: Use {{DeviceName}}para o CN RDN 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 assunto 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 para estar definido como 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 no campo CN (por exemplo, CN={{DeviceName}}), o SCEPman identificará o dispositivo com base no Intune Device ID ((URI)Valor: IntuneDeviceId://{{DeviceId}}) fornecido no nome alternativo do assunto (SAN).
Importante: A escolha do campo CN afeta o comportamento de revogação automática dos certificados emitidos para os seus dispositivos geridos pelo Intune.
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 assunto: (URI)Valor: IntuneDeviceId://{{DeviceId}}
O campo URI é recomendado pela Microsoft para soluções NAC identificarem os dispositivos com base no respetivo Intune Device ID. 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 assunto .
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 de o certificado expirar. O padrão é de um ano.
O SCEPman limita a validade do certificado ao máximo configurado na definição AppConfig:ValidityPeriodDays, mas, de resto, usa a validade configurada no pedido.
Fornecedor de armazenamento de chaves (KSP): Inscrever no Trusted Platform Module (TPM) KSP, caso contrário falha
Esta definição determina o local de armazenamento da chave privada para os certificados do utilizador final. O armazenamento no TPM é mais seguro do que o armazenamento por software, porque o TPM fornece uma camada adicional de segurança para impedir o roubo da chave.
Nota: Existe um erro em algumas versões mais antigas do firmware TPM que invalida algumas assinaturas criadas com uma chave privada suportada por TPM. Nestes casos, o certificado não pode ser usado para autenticação EAP, como é comum em ligações Wi‑Fi e VPN. Além disso, isto pode interromper o seu processo de integração do 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 usar TPM com este firmware, atualize o firmware para uma versão mais recente ou selecione "Software KSP" como fornecedor de armazenamento de chaves.
Atualização: Pode contornar o erro do TPM removendo os algoritmos de assinatura RSA-PSS - que estão a causar o problema - do registo; para mais informações, consulte o artigo de Richard Hicks e Microsoft Q&A
Utilização da chave: Assinatura digital e Cifragem de chave
Ative ambas as ações criptográficas.
O SCEPman define automaticamente a utilização da chave como Assinatura digital e Cifragem de chave e substitui a definição aqui, a menos que a definição AppConfig:UseRequestedKeyUsages esteja definida como true.
Root Certificate: Perfil da etapa anterior (perfil do certificado raiz)
Selecione o perfil do Intune em #Root Certificate. Se estiver a usar uma CA intermédia, tem de selecionar o perfil de certificado confiável para a CA intermédia, não para a CA raiz!
Utilização estendida da chave: Autenticação de cliente, 1.3.6.1.5.5.7.3.2
Escolha Autenticação de cliente (1.3.6.1.5.5.7.3.2) em Valores predefinidos. Os outros campos serão preenchidos automaticamente.
Limite de renovação (%): 20
Este valor define quando o dispositivo está autorizado a renovar o respetivo certificado (com base no tempo de vida restante de um certificado existente). Leia a nota em Período de validade do certificado e selecione um valor adequado que permita ao dispositivo renovar o certificado durante um longo período. Um valor de 20% permitiria ao dispositivo com um certificado válido por 1 ano iniciar a renovação 73 dias antes da expiração.
URLs do servidor SCEP: Abra o portal SCEPman e copie o URL de Intune MDM
Exemplo
Exemplo
Certificados de utilizador
Siga as instruções de #Device certificates e tenha em atenção as seguintes diferenças:
Formato do nome do assunto: CN={{UserName}},E={{EmailAddress}}
Pode definir RDNs com base nas suas necessidades. As variáveis suportadas estão listadas na documentação da Microsoft. Recomendamos incluir o nome de utilizador (por exemplo: janedoe) e o endereço de e-mail (por exemplo: [email protected]) como definição de base.
Nome alternativo do assunto: (UPN)Valor: {{UserPrincipalName}}
Tem de adicionar o nome principal do utilizador como nome alternativo do assunto. Adicione '{{UserPrincipalName}}' como Subject Alternative Name do tipo nome principal do utilizador (UPN). Isto garante que o SCEPman pode associar certificados a objetos de utilizador no AAD. A definição de "Formato do nome do assunto" é livremente selecionável.
Outros valores SAN, como um endereço de e-mail, 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 do utilizador quando este está armazenado no TPM. Tente inscrevê-lo no software KSP em alternativa.
Exemplo
Certificado de assinatura digital do utilizador
Pode usar o SCEPman para assinaturas digitais transacionais ou seja, para assinatura S/MIME no Microsoft Outlook. Se pretender usar os certificados para assinatura de mensagens, tem de adicionar as utilizações estendidas da chave correspondentes na configuração do perfil do Intune.
Não use SCEPman para encriptação de e-mail ou seja, para encriptação de correio S/MIME no Microsoft Outlook (sem uma tecnologia separada para gestão de chaves). A natureza de o protocolo SCEP não inclui um mecanismo para fazer backup ou arquivar o material da chave privada. Se usasse SCEP para encriptação de e-mail, poderia perder as chaves para desencriptar as mensagens mais tarde.
AppConfig:UseRequestedKeyUsagesdefinido comotrueAppConfig:ValidityPeriodDaysdefinido como365(é possível um valor máximo de 1825 - 5 anos)
Para implementar certificados de utilizador usados para Assinaturas Digitais siga as instruções de #User certificates e tenha em atenção as seguintes diferenças e notas:
Nome alternativo do assunto
(obrigatório) Nome principal do utilizador (UPN):
{{UserPrincipalName}}(obrigatório) Endereço de e-mail:
{{EmailAddress}}
Ao implementar um certificado de assinatura digital, tem de adicionar o UPN e o endereço de e-mail.
Utilização estendida da chave: Secure Email (1.3.6.1.5.5.7.3.4)
Escolha Secure Email (1.3.6.1.5.5.7.3.4) em Valores predefinidos. 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 são renovados pelo menos 6 meses antes da expiração ao emitir certificados de assinatura S/MIME. Isto deve-se ao facto de os e-mails assinados com certificados expirados aparecerem com assinaturas inválidas no Outlook, o que confunde os utilizadores. Ter um novo certificado muito antes de o antigo expirar garante que apenas os e-mails mais antigos mostram este comportamento, aos quais os utilizadores têm menos probabilidade de aceder. Por exemplo, se os seus certificados de assinatura forem válidos por um ano, deverá definir o Limite de renovação para, pelo menos, 50 %.
Exemplo
Após uma sincronização de perfil bem-sucedida, deverá ver o certificado do utilizador para Fins pretendidos Correio seguro
O certificado estará disponível para utilização de Assinatura Digital, por exemplo, no Outlook. Em baixo encontra-se um exemplo da utilização
Ativar assinaturas S/MIME no Outlook
Depois de implementar certificados de assinatura S/MIME nas suas máquinas cliente, tem de configurar o Outlook para usar estes certificados antes de enviar e-mails assinados.
Novo Outlook
O S/MIME para o novo Outlook pode ser configurado manualmente.
Outlook clássico
O S/MIME para o Outlook clássico pode ser configurado manualmente ou rapidamente configurado com o nosso script do PowerShell.
Outlook na Web
O S/MIME para o Outlook na Web pode ser configurado manualmente ou ativado com PowerShell através do seguinte comando:
Podem ser vistos comandos adicionais do PowerShell aqui.
Last updated
Was this helpful?