Android
Implementar certificados em dispositivos Android via SCEP usando o Intune e o SCEPman.
O artigo a seguir descreve como implementar um certificado de dispositivo ou de utilizador para Android. A implementação de certificados Android é semelhante às implementações de certificados do Windows 10, macOS e iOS.
O Android oferece dois conjuntos distintos de soluções: um é o perfil de trabalho (conhecido como Perfil de trabalho de propriedade pessoal) e o outro é o dispositivo totalmente gerido (também conhecido como Perfil de trabalho totalmente gerido, dedicado e de propriedade da empresa). Em ambos os cenários, as definições dos perfis de configuração de certificados permanecem consistentes.
A gestão por administrador de dispositivo Android foi lançada no Android 2.2 como forma de gerir dispositivos Android. Depois, a partir do Android 5, foi lançado o framework de gestão mais moderno do Android Enterprise (para dispositivos que se conseguem ligar de forma fiável aos Google Mobile Services). A Google está a incentivar a migração da gestão por administrador de dispositivo, reduzindo o suporte de gestão em novas versões do Android. Para mais informações, consulte MS. Intune Decreasing support for Android device admin
Root Certificate
A base para implementar certificados SCEP (de dispositivo ou de utilizador) é confiar no certificado raiz da 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 perfil SCEP. Caso contrário, a implementação do Intune pode falhar.
Certificados de dispositivo
Formato do nome do assunto: CN={{DeviceId}} ou CN={{AAD_Device_ID}}
O SCEPman usa o campo CN 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 (Recomendado). (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).
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 ID de dispositivo do Intune:
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.
Utilização da chave: Assinatura digital e encapsulamento de chave
Ative ambas as ações criptográficas.
Root Certificate: Perfil da etapa anterior
Selecione o perfil do Intune em [Root Certificate](android.md#root-certificate).
Se estiver a usar um CA intermédia, ainda assim tem de selecionar o perfil de certificado confiável para a CA raiz, e não para a CA intermédia!
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 deve adicionar o nome principal do utilizador como nome alternativo do sujeito. 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.
Outros valores SAN, como um endereço de e-mail, podem ser adicionados, se necessário.
É necessário ter um Nome alternativo do assunto no Certificado SCEP, Tipo de Utilizador. Sem um SAN, não tem acesso à rede Wi‑Fi da sua empresa.
Exemplo
Verificação de certificado
Para garantir a implementação correta de certificados no seu dispositivo Android, existem duas opções:
Em versões mais recentes do Android (por exemplo, 14), pode verificar certificados (de utilizador e confiáveis) a partir das definições > segurança e privacidade
Através de aplicações de terceiros como X509 Certificate Viewer Tool
Last updated
Was this helpful?