Tenancy dividido
Apenas SCEPman Enterprise Edition
Visão geral
O SCEPman pode ser configurado para funcionar a partir de um locatário Azure separado do locatário Azure/Intune para o qual emite certificados para usuários e/ou dispositivos. Esta configuração, conhecida como multi-locatário dividido (split-tenancy), é especialmente útil para MSPs que gostariam de consolidar os custos de infraestrutura do Azure entre seus clientes enquanto mantêm um backend dedicado e uma CA única para cada um desses clientes.
O split-tenancy traz consigo uma desvantagem importante: Identidades Gerenciadas não pode mais ser usado. Isso significa que a autenticação contra a API Graph (Azure AD e Intune) é realizada usando um registro de aplicativo e um segredo de cliente, que deve ser gerenciado (pelo MSP) quando expirar.
A seguir, nos referimos ao locatário anfitrião como locatário principal, enquanto ao locatário do cliente como locatário alvo. Os recursos do SCEPman existirão no locatário principal, e os dispositivos gerenciados no locatário alvo como no gráfico abaixo:
Etapas de Configuração
Na seção locatário principal, execute uma implantação padrão do SCEPman/Certificate Master conforme descrito em nosso Guia de Introdução.
No SCEPman (Locatário Principal)
Navegue até o App service do SCEPman App service e então em "Configurações" --> "Variáveis de ambiente". Localize os seguintes parâmetros e exclua eles:
AppConfig:AuthConfig:ManagedIdentityEnabledForWebsiteHostname
AppConfig:AuthConfig:ManagedIdentityEnabledOnUnixTime
AppConfig:AuthConfig:ManagedIdentityPermissionLevel
Renomeie as seguintes configurações (não altere os seus valores):
AppConfig:AuthConfig:ApplicationId
AppConfig:AuthConfig:HomeApplicationId
AppConfig:AuthConfig:TenantId
AppConfig:AuthConfig:HomeTenantId
Crie um registro de aplicativo no locatário alvo conforme descrito aqui: Registro de Aplicativo do Azure. Isto registro de aplicativo permitirá que o SCEPman acesse os diretórios Azure AD e Intune no locatário alvo.
O segredo de cliente gerado como parte deste registro de aplicativo tem uma expiração e deve ser renovado antes de expirar. Por favor, defina um lembrete para a renovação.
Criar as seguintes novas variáveis de ambiente se você ainda não o fez durante a criação do registro de aplicativo:
AppConfig:AuthConfig:ApplicationId
GUID do registro de aplicativo que foi criado antes (locatário alvo).
AppConfig:AuthConfig:TenantId
ID do locatário do locatário alvo.
AppConfig:AuthConfig:ApplicationKey
Valor do Segredo de cliente que foi criado como parte do registro de aplicativo no locatário alvo.
Aplique as alterações.
Reinicie o SCEPman App service.
Gerenciador de Certificados
Navegue até o Certificate Master App service e então em "Configurações" > "Variáveis de ambiente".
Agora você tem duas opções:
Se você quiser que usuários do seu locatário principal façam login no Certificate Master e emitam certificados, o que inclui usuários convidados no seu locatário principal, p.ex. do seu locatário alvo.
Se esse for o caso, renomeie as seguintes configurações (não altere os seus valores):
AppConfig:AuthConfig:TenantId
AppConfig:AuthConfig:HomeTenantId
AppConfig:AuthConfig:ApplicationId
AppConfig:AuthConfig:HomeApplicationId
b. Você quer que usuários do seu locatário alvo façam login no Certificate Master e emitam certificados, o que inclui usuários convidados no seu locatário alvo, p.ex. do seu locatário principal.
Se esse for o caso, faça o seguinte:
Abra uma PowerShell ou Azure Cloud Shell no seu locatário alvo e execute os seguintes comandos:
Substitua <url> com sua URL do Certificate Master
O CMDlet irá gerar um ID do Aplicativo e um ID do Locatário (aquele do locatário alvo). Insira esses dois valores como
AppConfig:AuthConfig:HomeApplicationIdeAppConfig:AuthConfig:HomeTenantIdnas configurações do seu Certificate Master.
Agora crie as seguintes novas configurações de aplicativo, possivelmente substituindo as existentes, com os mesmos valores que no SCEPman:
AppConfig:AuthConfig:ApplicationId
GUID do registro de aplicativo que foi criado antes.
AppConfig:AuthConfig:TenantId
ID do locatário do locatário alvo.
AppConfig:AuthConfig:ApplicationKey
Valor do Segredo de cliente que foi criado como parte do registro de aplicativo antes. Você pode criar um Segredo de Cliente separado e novo para o Certificate Master, se desejar.
Salve as alterações
Reinicie o SCEPman Certificate Master App service.
Conceda os direitos para solicitar certificados via o Gerenciador de Certificados aplicativo web, veja aqui
Como visão geral, aqui estão as contas usadas pelo Gerenciador de Certificados e para o que elas são usadas:
Identidade Gerenciada
Autorizar CSRs enviados ao SCEPman
Acesso à Conta de Armazenamento
N/D
Registro de Aplicativo com App ID de ApplicationId
O Certificate Master acessa o Microsoft Graph neste contexto para ver quais certificados foram inscritos via Intune
Se ApplicationKey não estiver presente, a Identidade Gerenciada é usada em vez disso.
Registro de Aplicativo com App ID de HomeApplicationId
Os usuários se autenticam para nesta aplicação. Ela deve estar no locatário onde os usuários que acessam o Certificate Master residem (mas usuários convidados de outros locatários também podem ser autorizados)
Se HomeApplicationId não estiver presente, ApplicationId é usado em vez disso.
Agora a configuração de Split-Tenancy está concluída, você pode prosseguir e configurar seus perfis SCEP com base no seu MDM, veja aqui
Considerações ao ter múltiplos locatários alvo
Se você quiser ter múltiplas instâncias do SCEPman para emitir certificados para diferentes locatários alvo, você desejará tomar passos adicionais de configuração para isolar essas instâncias umas das outras.
Um conceito possível poderia incluir um grupo de recursos de gerenciamento que contenha um único App Service Plan que fornecerá o recurso de computação para todos os seus App Services SCEPman. Os seguintes pontos devem ser considerados ao fazer isso para múltiplos locatários:
Cada instância deve ter seu próprio grupo de recursos para distingui-las
Você deve criar Registros de Aplicativos para cada instância para isolar as permissões
O App Service Plan deve ser criado em um grupo de recursos de gerenciamento independente, pois ele serve múltiplas instâncias
Neste diagrama, um locatário de gerenciamento e suas duas instâncias SCEPman fornecem certificados aos locatários da Contoso e da Tailwind:
Unexpected error with integration mermaid: Integration is not installed on this space
Adicionar uma nova instância SCEPman a um App Service Plan existente
Ao implantar uma nova instância SCEPman usando o método de implantação empresarial você tem a possibilidade de inserir o id do recurso de um App Service Plan existente ao qual essa instância deve ser adicionada.
Esse id de recurso pode ser encontrado nas propriedades do plano de serviço de aplicativo existente:
Criar registros de aplicativo específicos para o cliente
Para isolar as permissões dos aplicativos você precisará ajustar o comando pós-implantação para especificar Registros de Aplicativo personalizados:
Este comando resultará em uma instância SCEPman totalmente configurada que está isolada das instâncias anteriores. Você agora pode prosseguir para configurar o split-tenancy para esta instância.
A seção acima referente ao Certificate Master agora pode ser aplicada opcionalmente se você quiser que este serviço seja acessível a partir do locatário do cliente.
Last updated
Was this helpful?