Este artigo foi traduzido automaticamente. A tradução pode conter imprecisões.
Alternar para a versão original em inglês.
Ctrlk
linkedinx-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Configuração geral

Para permitir que o SCEPman trate com sucesso os pedidos SOAP recebidos, precisamos de seguir alguns passos:

1

Domínio personalizado

Para uma autenticação bem-sucedida com o SCEPman, certifique-se de que um domínio personalizado usando um registro A está apontado para o App Service. Caso contrário, o cliente não conseguirá solicitar um ticket Kerberos válido do Domain Controller.

O domínio personalizado não precisa de se assemelhar ao FQDN do seu domínio AD. Portanto, ter um domínio ad.contoso.local não significa que precise de um domínio personalizado idêntico ou semelhante para o SCEPman.

Consulte o problema conhecido abaixo relativo a WS_E_ENDPOINT_ACCESS_DENIED para mais informações.

Certifique-se de que o SCEPman está configurado para ser acessível usando um domínio personalizado:

Domínio personalizado
2

BaseUrl

Para permitir autenticações bem-sucedidas, certifique-se de que a AppConfig:BaseUrl variável corresponde ao seu domínio personalizado.

Definição
Valor

AppConfig:BaseUrl

Exemplo: scepman.contoso.com

Em alternativa, se preferir aceder ao Endpoint do AD usando um URL diferente dos seus outros endpoints do SCEPman, use a definição dedicada AppConfig:ActiveDirectory:BaseUrl definição.

Definição
Valor

AppConfig:ActiveDirectory:BaseUrl

Exemplo: adendpoint.contoso.com

3

Criar Service Principal

Use o New-SCEPmanADPrincipal Cmdlet do módulo PowerShell do SCEPman para criar o Service Principal no seu domínio local do Active Directory. Também exportará um keytab desta conta e encriptá-lo-á com o certificado CA do SCEPman.

Pode executar este comando num Domain Controller ou num servidor associado ao domínio que tenha instalada a RSAT-AD-Tools funcionalidade. Também precisará das seguintes permissões na OU em que pretende criar o principal:

Na própria OU:

  • Criar objetos de computador

Nos objetos de computador descendentes:

  • Repor palavra-passe

  • Escrever msDS-SupportedEncryptionTypes

  • Escrever servicePrincipalName

  • Escrever userPrincipalName

A variante abaixo também requer acesso de rede HTTPS de saída à sua instância do SCEPman.

Se o seu computador com acesso a um Domain Controller não tiver acesso à rede, existem variantes do CMDlet que funcionam sem isso, mas requerem alguma preparação adicional, como transferir o certificado CA do SCEPman e copiar a CA para a máquina que executa o CMDlet.

Install-Module SCEPman -Force
New-SCEPmanADPrincipal -Name "SCEPmanAD" -AppServiceUrl "scepman.contoso.com" -OU
"OU=Example,DC=contoso,DC=local"

Executar este comando fará o seguinte:

  1. Criar um objeto de computador na OU=Example,DC=contoso,DC=local Unidade Organizacional.

  2. Transferir o certificado CA do SCEPman para encriptar o keytab no passo 5.

  3. Adicionar um nome de principal de serviço (SPN) ao objeto de computador.

  4. Criar um keytab para a conta de computador contendo a chave de encriptação com base na palavra-passe do computador.

  5. Encriptar o keytab com o certificado CA do SCEPman, para que apenas o SCEPman o possa desencriptar novamente usando a chave privada da CA.

  6. Gerar a saída do keytab encriptado, para que possa ser transferido para a configuração do SCEPman.

A saída codificada em Base64 deve então ser adicionada à variável de ambiente AppConfig:ActiveDirectory:Keytab no seu App Service do SCEPman.

4

Adicionar Keytab ao SCEPman

A integração pode ser facilmente ativada adicionando as seguintes variáveis de ambiente no App Service do SCEPman. Dependendo do seu caso de uso, ative um ou mais dos modelos de certificado disponíveis:

Exemplo com todos os modelos de certificado ativados:

Definição
Valor

AppConfig:ActiveDirectory:Keytab

Keytab codificado em Base64 para o Service Principal criado em Passo 3

AppConfig:ActiveDirectory:Computer:Enabled

true

AppConfig:ActiveDirectory:User:Enabled

true

AppConfig:ActiveDirectory:DC:Enabled

true

AppConfig:ActiveDirectory:RdpServer:Enabled

true

Problemas conhecidos

WS_E_ENDPOINT_ACCESS_DENIED

Erro: WS_E_ENDPOINT_ACCESS_DENIED 
Hex: 0x803d0005
Dec: -2143485947

Sabe-se que este erro ocorre durante a validação do servidor CEP quando está a utilizar os padrão URI do Azure App Service. Este erro é causado pelo protocolo Kerberos ao pedir um nome de principal de serviço do registro A serviço a que se pretende aceder. No caso dos domínios padrão do app service, por exemplo contoso.azurewebsites.net é um CNAME e aponta para um registro A semelhante a:

waws-prod-ab1-234-c56d.westeurope.cloudapp.azure.com

Como este registro A de um host de infraestrutura não é garantido que seja consistente no futuro, adicionar um nome de principal de serviço para este host é não recomendado.

Certifique-se de adicionar um domínio personalizado ao seu app service e usar um registro A no seu fornecedor de DNS para o apontar para o app service em vez de um CNAME.

Domínio personalizado

ERROR_INVALID_PARAMETER

Erro: ERROR_INVALID_PARAMETER
Hex: 0x80070057
Dec: -2147024809

Este erro ocorre durante o registo do servidor CEP se introduzir um URI que comece com http://. Certifique-se de registar um servidor CEP apenas usando https:// .

ERROR_ACCESS_DENIED

Ao registar um servidor CEP no contexto da máquina, o utilizador atuante (a conta que iniciou gpmc.msc) precisa de ser membro do grupo local Administrators no computador enquanto edita a GPO.

Certifique-se de iniciar gpmc.msc com permissões elevadas neste caso.

Última atualização

Isto foi útil?