Windows
Implante certificados em dispositivos Windows via SCEP no Intune usando SCEPman.
O artigo a seguir descreve a implementação de certificados de dispositivo ou/e de utilizador para dispositivos Windows. A implementação do certificado raiz do SCEPman é obrigatória. Depois, pode escolher entre implementar apenas os tipos de certificado de dispositivo, de utilizador ou até ambos.
Certificado raiz
A base para a implementação de certificados SCEP é confiar no certificado raiz do SCEPman. Portanto, tem de descarregar o certificado raiz da CA e implementá-lo como um certificado confiável perfil via Microsoft Intune:


Note 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 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 pesquisar 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 AppConfig:IntuneValidation:DeviceDirectory 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}} seja usado para o campo CN (por exemplo, CN={{DeviceName}}), o SCEPman identificará o dispositivo com base no ID do dispositivo Intune ((URI)Valor: IntuneDeviceId://{{DeviceId}}) fornecido no nome alternativo do sujeito (SAN).
Pode especificar estas variáveis e texto estático na caixa de texto. Por exemplo, o nome comum de um dispositivo denominado Device1 pode ser adicionado como CN={{DeviceName}}YourDomain.com
Importante: A escolha do campo CN afeta o comportamento automático de revogação 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 nos documentos 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 respetivo ID do dispositivo 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 de o certificado expirar. O padrão é definido para 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, falhar
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 evitar o roubo de chaves.
Nota: Existe um erro em algumas versões antigas do firmware TPM que invalida algumas assinaturas criadas com uma chave privada baseada em TPM. Nesses 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
Uso da chave: Assinatura digital e Encapsulamento de chaves
Ative ambas as ações criptográficas.
O SCEPman define automaticamente o uso da chave para Assinatura digital e Encapsulamento de chaves e substitui a definição aqui, a menos que a definição AppConfig:UseRequestedKeyUsages seja definida como true.
Certificado raiz: Perfil do passo anterior (perfil do certificado raiz)
Selecione o perfil do Intune em #Certificado raiz. Se estiver a usar uma CA intermédia, tem de selecionar o perfil de certificado Confiável para a CA intermédia, e não para a CA raiz!
Uso prolongado 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 pode 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 que um dispositivo com um certificado válido por 1 ano iniciasse 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 #Certificados de dispositivo e tenha em conta as seguintes diferenças:
Formato do nome do sujeito: CN={{UserName}},E={{EmailAddress}}
Pode definir RDNs com base nas suas necessidades. As variáveis suportadas estão listadas nos documentos da Microsoft. Recomendamos incluir o nome de utilizador (por exemplo: janedoe) e o endereço de e-mail (por exemplo: janedoe@contoso.com) como definição de base.
Nome alternativo do sujeito: (UPN)Valor: {{UserPrincipalName}}
Tem de adicionar o nome principal do utilizador como o nome alternativo do sujeito. Adicione '{{UserPrincipalName}}' como Nome Alternativo do Sujeito do tipo nome principal do utilizador (UPN). Isto garante que o SCEPman pode associar certificados a objetos de utilizador no AAD. A definição para "Formato do nome do sujeito" é 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 vez disso.
Exemplo

Certificado de assinatura digital de utilizador
Pode usar o SCEPman para assinaturas digitais isto é, para assinatura S/MIME no Microsoft Outlook. Se pretender usar os certificados para assinatura de mensagens, tem de adicionar os usos prolongados da chave correspondentes na configuração do perfil Intune.
Não use o SCEPman para encriptação de e-mail isto é, 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 material de chave privada. Se usasse SCEP para encriptação de e-mail, poderá perder as chaves para desencriptar as mensagens mais tarde.
AppConfig:UseRequestedKeyUsagesdefinido paratrueAppConfig:ValidityPeriodDaysdefinido para365(é possível um valor máximo de 1825 - 5 anos)
Para implementar certificados de utilizador usados para Assinaturas digitais siga as instruções de #Certificados de utilizador e tenha em conta as seguintes diferenças e notas:
Nome alternativo do sujeito
(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.
Uso prolongado da chave: Correio seguro (1.3.6.1.5.5.7.3.4)
Escolha Correio seguro (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 sejam 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 no Outlook como tendo assinaturas inválidas, o que confunde os utilizadores. Ter um novo certificado muito antes de o antigo expirar garante que apenas os e-mails mais antigos apresentem este comportamento, sendo mais improvável que os utilizadores os consultem. 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 em Finalidades pretendidas Correio seguro

O certificado estará disponível para uso de Assinatura digital, por exemplo, no Outlook. Abaixo está um exemplo do uso

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 configurado rapidamente com o nosso Script do PowerShell.
Outlook na Web
O S/MIME para o Outlook na Web pode ser configurado manualmente ou ativado usando o PowerShell com o seguinte comando:
Comandos adicionais do PowerShell podem ser consultados aqui.
Última atualização
Isto foi útil?