Referência Técnica para Controlos de Criptografia Utilizados no Configuration Manager

As atribuições de políticas de cliente são assinadas pelo certificado de assinatura autoassinado do servidor do site para ajudar a evitar o risco de segurança que representa o envio de políticas que tenham sido adulteradas por um ponto de gestão comprometido. Esta salvaguarda é especialmente relevante se estiver a utilizar gestão de clientes baseados na Internet, uma vez que este ambiente requer um ponto de gestão exposto a comunicações de Internet.

A política é encriptada com o algoritmo 3DES quando contém dados confidenciais. Políticas que contenham dados confidenciais são enviadas apenas para clientes autorizados. Políticas que não tenham dados confidenciais não são encriptadas.

Quando a política é armazenada nos clientes, é encriptada utilizando a interface de programação de aplicações da Proteção de Dados (DPAPI).

Quando os clientes do Gestor de configuração pedem políticas, obtêm primeiro uma atribuição de políticas para saberem as políticas que se lhes aplicam e, em seguida, pedem apenas os corpos dessas política. Cada atribuição de política contém o hash calculado para o corpo da política correspondente. O cliente obtém os corpos de políticas aplicáveis e calcula o hash desses corpos. Se o hash contido no corpo de política transferido não corresponder ao hash na atribuição de política, o cliente rejeita o corpo de política.

Os algoritmos hash para políticas são SHA-1 e SHA-256.

O serviço de gestão de distribuição no servidor do site calcula o hash dos ficheiros de conteúdo de todos os pacotes. O fornecedor de política inclui o hash na política de distribuição de software. Quando o cliente do Gestor de configuração transfere o conteúdo, gera de novo o hash localmente e compara-o com o fornecido na política. Se os hashes coincidirem, o conteúdo não foi alterado e o cliente instala-o. Se um único byte do conteúdo tiver sido alterado, os hashes não coincidirão e o software não será instalado. Esta verificação ajuda a garantir que é instalado o software correto, uma vez que o conteúdo real é verificado em relação à política.

O algoritmo hash predefinido para conteúdo é o SHA-256. Para alterar esta predefinição, consulte a documentação do Software Development Kit (SDK) do Gestor de configuração.

Nem todos os dispositivos suportam hash de conteúdo. Seguem-se algumas das exceções:

• Clientes Windows, quando transmitem em fluxo conteúdo de App-V.

• Clientes Windows Phone. No entanto, estes clientes verificam a assinatura de uma aplicação que esteja assinada por uma origem fidedigna.

• Clientes Windows RT. No entanto, estes clientes verificam a assinatura de uma aplicação que esteja assinada por uma origem fidedigna e também utilizam a validação do nome completo do pacote (PFN).

• iOS. No entanto, estes dispositivos verificam a assinatura de uma aplicação que esteja assinada por qualquer certificado de programador de uma origem fidedigna.

• Clientes Nokia. No entanto, estes clientes verificam a assinatura de uma aplicação que utilize um certificado autoassinado. Em alternativa, a assinatura de um certificado de uma origem fidedigna e o certificado podem assinar aplicações SIS (Symbian Installation Source) da Nokia.

• Android. Além disso, estes dispositivos não utilizam validação de assinaturas para instalação de aplicações.

• Os clientes executados em versões do Linux e UNIX que não suportam SHA-256. Para obter mais informações, consulte a secção do tópico Planear a implementação de clientes para Linux e servidores UNIX.da15f702-ba6a-40fb-b130-c624f17e2846#BKMK_NoSHA-256

O inventário que os clientes enviam para os pontos de gestão é sempre assinado pelos dispositivos, independentemente de comunicarem com os pontos de gestão por HTTP ou HTTPS. Se utilizarem HTTP, pode optar por encriptar estes dados, que é a melhor prática de segurança.

Os dados armazenados em pontos de migração de estado da implementação de sistemas operativos são sempre encriptados pela Ferramenta de Migração de Estado de Utilizador (USMT) utilizando 3DES.

Para cada pacote de implementação de sistema operativo, pode ativar a encriptação quando o pacote for transferido para computadores através da utilização de multicast. A encriptação utiliza a norma AES (Advanced Encryption Standard). Se ativar a encriptação, não é necessária qualquer configuração adicional de certificados. O ponto de distribuição de capacidade multicast gera automaticamente chaves simétricas para encriptar o pacote. Cada pacote tem uma chave de encriptação diferente. A chave é armazenada no ponto de distribuição de capacidade multicast utilizando APIs padrão do Windows. Quando o cliente liga à sessão multicast, a troca de chaves ocorre através de um canal encriptado com o certificado de autenticação de cliente emitido pela PKI (quando o cliente utilizar HTTPS) ou o certificado autoassinado (quando o cliente utilizar HTTP). O cliente armazena a chave na memória apenas durante a sessão multicast.

Quando utiliza suportes de dados para implementar sistemas operativos e especifica uma palavra-passe para proteger os suportes de dados, as variáveis de ambiente são encriptadas utilizando AES (Advanced Encryption Standard). Outros dados existentes no suporte de dados, incluindo pacotes e conteúdo de aplicações, não estão encriptados.

A partir do System Center 2012 Configuration Manager SP1, ao utilizar pontos de distribuição baseados na nuvem, o conteúdo que carregar nestes pontos de distribuição será encriptado através de AES (Advanced Encryption Standard) com um tamanho de chave de 256 bits. O conteúdo será novamente encriptado sempre que for atualizado. Quando os clientes transferirem o conteúdo, este será encriptado e protegido pela ligação HTTPS.

Todas as atualizações de software têm de ser assinadas por um fabricante fidedigno para proteção contra adulteração. Em computadores cliente, o Windows Update Agent (WUA) procura as atualizações no catálogo, mas não instalará uma atualização se não conseguir localizar o certificado digital no arquivo Fabricantes Fidedignos no computador local. Se tiver sido utilizado um certificado autoassinado para publicar as atualizações no catálogo, como o certificado autoassinado WSUS Publishers, este terá de constar também no arquivo de certificados Autoridades de Certificação de Raiz Fidedigna, no computador local, para verificação da validade do certificado. O WUA também verifica se a definição de Política de Grupo Permitir conteúdo assinado da localização do serviço de atualização da Microsoft na intranet está ativada no computador local. Esta definição de política tem de estar ativada para que o WUA procure atualizações criadas e publicadas com o Updates Publisher.

Quando as atualizações de software são publicadas no System Center Updates Publisher, são assinadas por um certificado digital quando são publicadas ou atualizadas num servidor. Pode especificar um certificado PKI ou configurar o Updates Publisher para gerar um certificado autoassinado para assinar a atualização de software.

Quando importa dados de configuração, o Gestor de configuração verifica a assinatura digital do ficheiro. Se os dados não tiverem sido assinados ou se a verificação da assinatura digital falhar, será apresentado um aviso e será perguntado se pretende continuar com a importação. Continue a importar os dados de configuração apenas se confiar explicitamente no fabricante e na integridade dos ficheiros.

Se utilizar notificações de cliente, todas as comunicações utilizarão TLS e a encriptação mais elevada que os sistemas operativos do servidor e do cliente possam negociar. Por exemplo, um computador cliente com o Windows 7 e um ponto de gestão com o Windows Server 2008 R2 suportam encriptação AES de 128 bits, enquanto um computador cliente com o Vista e o mesmo ponto de gestão negociarão com a encriptação 3DES. A mesma negociação ocorre para o hash dos pacotes que são transferidos durante a notificação do cliente, que utiliza SHA-1 ou SHA-2.

Se o dispositivo móvel não tiver sido bloqueado pela operadora de rede móvel, pode utilizar o Gestor de configuração ou o Microsoft Intune para pedir e instalar um certificado de cliente. Este certificado fornece autenticação mútua entre o cliente do dispositivo móvel e os sistemas de sites do Gestor de configuração ou os serviços do Microsoft Intune. Se o dispositivo móvel estiver bloqueado, não será possível utilizar o Gestor de configuração nem o Intune para implementar certificados. Para mais informações, consulte Como Instalar Clientes em Dispositivos Móveis e Inscrevê-los Através do Configuration Manager.

Se ativar o inventário de hardware para dispositivos móveis, o Gestor de configuração ou o Intune também fará um inventário dos certificados instalados no dispositivo móvel.

A gestão fora de banda de computadores baseados em Intel AMT utiliza, pelo menos, dois tipos de certificados emitidos pela PKI: um certificado de aprovisionamento AMT e um certificado do servidor Web.

O ponto de serviço fora de banda utiliza um certificado de aprovisionamento de AMT para preparar os computadores para a gestão fora de banda. Os computadores baseados em AMT que serão aprovisionados têm de considerar fidedigno o certificado apresentado pelo ponto de gestão fora de banda. Por predefinição, os computadores baseados em AMT são configurados pelo fabricante de computadores para utilizar autoridades de certificação (AC) externas, como a VeriSign, Go Daddy, Comodo e Starfield. Se adquirir um certificado de aprovisionamento de uma das CAs externas e configurar o Gestor de configuração para utilizar este certificado de aprovisionamento, os computadores baseados em AMT considerarão fidedigna a AC do certificado de aprovisionamento e o aprovisionamento terá êxito. No entanto, a utilização de uma AC interna própria para emitir o certificado de aprovisionamento de AMT constitui uma melhor prática de segurança. Para mais informações, consulte Segurança práticas recomendadas para gestão fora de banda.

Os computadores baseados em AMT executam um componente de servidor Web no respetivo firmware e esse componente encripta o canal de comunicações com o ponto de serviço fora de banda utilizando TLS (Transport Layer Security). O BIOS de AMT não tem interface de utilizador para configuração manual de um certificado, pelo que necessita de uma autoridade de certificação empresarial da Microsoft que aprove automaticamente os pedidos de certificado de computadores baseados em AMT. O pedido utiliza PKCS#10 como formato do pedido, que, por sua vez, utiliza PKCS#7 para a transmissão das informações do certificado para o computador baseado em AMT.

Apesar de o computador baseado em AMT efetuar a autenticação no computador que o gere, não existe nenhum certificado PKI de cliente correspondente neste computador. Em vez disso, estas comunicações utilizam autenticação Kerberos ou autenticação de Texto Implícita por HTTP. Quando é utilizada a autenticação de Texto Implícita por HTTP, é encriptada utilizando TLS.

Poderá ser necessário um tipo de certificado adicional para gerir computadores baseados em AMT fora de banda: um certificado de cliente opcional para redes com e sem fios com autenticação 802.1X. O computador baseado em AMT poderá necessitar do certificado de cliente para autenticação no servidor RADIUS. Quando o servidor RADIUS está configurado para autenticação EAP-TLS, é sempre necessário um certificado de cliente. Quando o servidor RADIUS está configurado para EAP-TTLS/MSCHAPv2 ou PEAPv0/EAP-MSCHAPv2, a configuração RADIUS especifica se é necessário um certificado de cliente ou não. Este certificado é pedido pelo computador baseado em AMT utilizando os mesmos processos do pedido de certificado de servidor Web.

Quando utiliza o Gestor de configuração para implementar sistemas operativos, e um ponto de gestão requer ligações de cliente HTTPS, o computador cliente terá de ter também um certificado para comunicar com o ponto de gestão, mesmo que se encontre numa fase transitória, por exemplo, a iniciar a partir de um suporte de dados de sequência de tarefas ou de um ponto de distribuição com PXE. Neste cenário, terá de criar um certificado de autenticação de cliente PKI e exportá-lo com a chave privada e, em seguida, importá-lo para as propriedades do sistema de sites e adicioná-lo também ao certificado da AC de raiz fidedigna do ponto de gestão.

Se criar suportes de dados de arranque, importa o certificado de autenticação de cliente quando criar o suporte de dados de arranque. Configure uma palavra-passe no suporte de dados de arranque para ajudar a proteger a chave privada e outros dados confidenciais configurados na sequência de tarefas. Os computadores que iniciam a partir do suporte de dados de arranque irão apresentar o mesmo certificado ao ponto de gestão tal como necessário para as funções dos clientes, como o pedido de política de cliente.

Se estiver a utilizar o arranque PXE, importará o certificado de autenticação de cliente para o ponto de distribuição ativado com PXE, que utiliza o mesmo certificado para todos os clientes que iniciam a partir de um ponto de distribuição ativado com PXE. Como procedimento recomendado de segurança, solicite aos utilizadores que liguem os computadores a um serviço PXE para fornecer uma palavra-passe que ajude a proteger a chave privada e outros dados confidenciais nas sequências de tarefas.

Se algum destes certificados de autenticação de cliente for comprometido, bloqueie os certificados no nó Certificados na área de trabalho Administração, nó Segurança. Para gerir estes certificados, tem de ter a definição Gerir certificado de implementação do sistema operativo correta.

Depois de o sistema operativo ser implementado e o Gestor de configuração ser instalado, o cliente necessitará do seu próprio certificado de autenticação de cliente PKI para a comunicação de cliente por HTTPS.

Os Fabricantes Independentes de Software (ISV) podem criar aplicações que expandem o Gestor de configuração. Por exemplo, um ISV poderia criar extensões para suportar plataformas de cliente não Windows, tais como computadores Macintosh ou UNIX. No entanto, se os sistemas de sites precisarem de ligações cliente HTTPS, estes clientes têm também de utilizar certificados KPI para a comunicação com o site. O Gestor de configuração inclui a capacidade de atribuir um certificado ao proxy ISV que permite as comunicações entre os clientes proxy ISV e o ponto de gestão. Se utilizar extensões que requerem certificados de proxy ISV, consulte a documentação desse produto. Para mais informações sobre como criar certificados de proxy ISV, consulte o Gestor de configuração Software Developer Kit (SDK).

Se o certificado ISV for comprometido, bloqueie o certificado no nó Certificados na área de trabalho Administração, nó Segurança.

O Gestor de configuração é instalado com um certificado X.509 que o ponto de sincronização do Asset Intelligence utiliza para se ligar à Microsoft. O Gestor de configuração utiliza este certificado para pedir um certificado de autenticação de cliente ao serviço de certificados da Microsoft. O certificado de autenticação de cliente é instalado no servidor de sistema de site do ponto de sincronização do Asset Intelligence e é utilizado para autenticar o servidor para a Microsoft. O Configuration Manager utiliza o certificado de autenticação de cliente para transferir o catálogo do Asset Intelligence e para carregar os títulos de software.

Este certificado tem um comprimento de chave de 1024 bits.

A partir do System Center 2012 Configuration Manager SP1, os pontos de distribuição baseados na nuvem exigem um certificado de gestão ( auto-assinado ou PKI) que tem de carregar para o Microsoft Azure. Este certificado de gestão requer a capacidade de autenticação de servidor e um comprimento de chave do certificado de 2048 bits. Além disso, é necessário configurar um certificado de serviço para cada ponto de distribuição baseado na nuvem, que não pode ser autoassinado mas tem de ter capacidade de autenticação de servidor e um comprimento de chave do certificado mínimo de 2048 bits.

Os clientes não necessitam de um certificado PKI de cliente para utilizarem pontos de distribuição baseados na nuvem; eles procedem à autenticação para a gestão através da utilização de um certificado autoassinado ou um certificado PKI de cliente. O ponto de gestão emite um token de acesso do Gestor de configuração para o cliente, que o cliente apresenta ao ponto de distribuição baseado na nuvem. O token é válido durante 8 horas.

Quando o Microsoft Intune inscreve dispositivos móveis, pode gerir estes dispositivos móveis no Gestor de configuração ao criar um conector do Microsoft Intune. O conector utiliza um certificado PKI com capacidade de autenticação de cliente para autenticar o Gestor de configuração para o Microsoft Intune e para transferir todas as informações entre eles através de SSL. A chave do certificado tem o tamanho de 2048 bits e utiliza o algoritmo hash SHA-1.

Quando o conector é instalado, é criado um certificado de assinatura e armazenado no servidor do site para chaves de sideload e é criado um certificado de encriptação e armazenado no ponto de registo de certificados para encriptar o desafio SCEP (Simple Certificate Enrollment Protocol). Estes certificados também têm um tamanho de chave de 2048 bits e utilizam o algoritmo hash SHA-1.

Quando o Intune inscreve dispositivos móveis, instala um certificado PKI no dispositivo móvel. Este certificado tem capacidade de autenticação de cliente, utiliza um tamanho de chave de 2048 bits e utiliza o algoritmo hash SHA-1.

Estes certificados PKI são automaticamente pedidos, gerados e instalados através do Microsoft Intune.

Uma lista de revogação de certificados PKI (CRL) aumenta a sobrecarga administrativa e de processamento, mas apresenta mais segurança. No entanto, se a verificação CRL está ativada, mas a CRL está inacessível, a ligação de PKI falha. Para obter mais informações, consulte a secção Planear a Revogação de Certificados PKI do tópico Planear Segurança no Configuration Manager.

A verificação da lista de revogação de certificados (CRL) é ativada por predefinição no IIS, portanto, se está a utilizar uma CRL com a sua implementação PKI, não há nada adicional a configurar na maior parte dos sistemas de sites do Gestor de configuração que executam o IIS. A exceção é para atualizações de software, que requerem um passo manual para ativar a verificação CRL para verificar as assinaturas nos ficheiros de atualização de software.

A verificação CRL está ativada por predefinição para computadores cliente quando utilizam ligações de cliente HTTPS. A verificação CRL não é ativada por predefinição quando é executada a consola de Gestão Fora de Banda para ligar a um computador baseado em AMT, sendo possível ativar esta opção. Não é possível desativar a verificação CRL para os clientes em computadores Mac no Gestor de configuração SP1 ou posterior.

A verificação CRL não é suportada para as seguintes ligações no Gestor de configuração:

• Ligações de servidor a servidor.

• Dispositivos móveis que são inscritos pelo Gestor de configuração.

• Dispositivos móveis que são inscritos pelo Microsoft Intune.

Cada servidor de sistema de sites utiliza um certificado para transferir dados para outros sistemas de sites no mesmo site do Gestor de configuração. Algumas funções de sistema do site também utilizam certificados para autenticação. Por exemplo, se instalar o ponto proxy de registo num servidor e o ponto de registo noutro servidor, eles podem autenticar-se entre si utilizando este certificado de identidade. Quando o Gestor de configuração utiliza um certificado para esta comunicação, se existir um certificado PKI disponível com capacidade de autenticação, o Gestor de configuração utiliza-o automaticamente; caso contrário, o Gestor de configuração gera um certificado autoassinado. Este certificado autoassinado tem capacidade de autenticação de servidor, utiliza SHA-256 e tem um comprimento de chave de 2048 bits. O Gestor de configuração copia o certificado para o arquivo Pessoas Fidedignas noutros servidores de sistema de sites que podem necessitar de fidedignidade do sistema de sites. Os sistemas de sites podem depois confiar um do outro utilizando estes certificados e PeerTrust.

Além deste certificado para cada servidor de sistema de sites, o Gestor de configuração gera um certificado autoassinado para a maior parte das funções do sistema de sites. Quando existe mais do que uma instância da função de sistema do site no mesmo site, elas partilham o mesmo certificado. Por exemplo, pode ter vários pontos de gestão ou vários pontos de registo no mesmo site. Este certificado autoassinado também utiliza SHA-256 e tem um comprimento de chave de 2048 bits. É também copiado para o Arquivo de Pessoas Fidedignas nos servidores de sistema do site que poderão necessitar de confiar nele. As seguintes funções de sistema do site geram este certificado:

• Ponto de serviço Web do Catálogo de Aplicações

• Ponto de Web site do Catálogo de Aplicações

• Ponto de sincronização do Asset Intelligence

• Ponto de registo de certificados

• Ponto de Endpoint Protection

• Ponto de inscrição

• Ponto de estado de contingência

• Ponto de gestão

• Ponto de distribuição com multicast ativado

• Ponto de serviço fora de banda

• Ponto do Reporting Services

• Ponto de atualização de Software

• Ponto de migração de estado

• Ponto de Validação do Estado de Funcionamento do Sistema

• Conector do Microsoft Intune

Estes certificados são geridos automaticamente pelo Gestor de configuração e, sempre que necessário, são gerados automaticamente.

O Gestor de configuração também utiliza um certificado de autenticação de cliente para enviar mensagens de estado do ponto de distribuição para o ponto de gestão. Quando o ponto de gestão está configurado apenas para ligações de cliente HTTPS, é necessário utilizar um certificado PKI. Se o ponto de gestão aceita ligações HTTP, é possível utilizar um certificado PKI ou selecionar a opção para utilizar um certificado autoassinado que tenha capacidade de autenticação de cliente, utilize SHA-256 e tenha um comprimento de chave de 2048 bits.

O Gestor de configuração transfere dados entre sites utilizando a replicação de base de dados e a replicação baseada em ficheiros. Para mais informações, consulte Referência Técnica para Comunicações de Site no Configuration Manager.

O Gestor de configuração configura automaticamente a replicação da base de dados entre sites e utiliza certificados PKI que tenham capacidade de autenticação de servidor se estes estiverem disponíveis; caso contrário, o Gestor de configuração cria certificados autoassinados para autenticação de servidor. Em ambos os casos, a autenticação entre sites é estabelecida utilizando os certificados do Arquivo de Pessoas Fidedignas que utilize PeerTrust. Este arquivo de certificados é utilizado para garantir que apenas os computadores com SQL Server que são utilizados pela hierarquia do Gestor de configuração participam na replicação site a site. Enquanto os sites primários e o site de administração central podem replicar alterações à configuração de todos os sites na hierarquia, os sites secundários podem replicar alterações à configuração apenas do respetivo site principal.

Os servidores de site estabelecem comunicação site a site através da utilização de uma troca de chaves segura que ocorre automaticamente. O servidor de site remetente gera um hash e assina-o com a respetiva chave privada. O servidor de site recetor verifica a assinatura, utilizando a chave pública e compara o hash com um valor gerado localmente. Se coincidirem, o site recetor aceita os dados replicados. Se os valores não corresponderem, o Gestor de configuração rejeita os dados de replicação.

A replicação de base de dados no Gestor de configuração utiliza o SQL Server Service Broker para transferir dados entre sites utilizando os mecanismos seguintes:

• Ligação SQL Server a SQL Server: Esta opção utiliza as credenciais do Windows para autenticação de servidor e certificados autoassinados com 1024 bits, para assinar e encriptar os dados utilizando AES (Advanced Encryption Standard). Se existirem certificados PKI com capacidade de autenticação de servidor disponíveis, serão utilizados. O certificado tem de estar localizado no arquivo Pessoal para o arquivo de certificados de Computador.

• SQL Service Broker: Esta opção utiliza os certificados autoassinados com 2048 bits para assinar e encriptar os dados utilizando AES (Advanced Encryption Standard). O certificado tem de estar localizado na base de dados mestre do SQL Server.

A replicação baseada em ficheiros utiliza o protocolo Bloco de Mensagem de Servidor (SMB) e utiliza SHA-256 para assinar estes dados que não estão encriptados mas não contêm dados confidenciais. Se pretende encriptar estes dados pode utilizar IPsec, devendo proceder a esta implementação independentemente do Gestor de configuração.

Quando os clientes comunicam com sistemas de sites utilizando HTTPS, as comunicações são geralmente encriptadas através de SSL. No entanto, nas seguintes situações, os clientes comunicam com sistemas de sites sem utilizar a encriptação:

• O cliente não consegue efetuar uma ligação HTTPS através da intranet e reverter para a utilização de HTTP quando os sistemas de sites permitem esta configuração

• Comunicação para as seguintes funções de sistema do site:

  • O cliente envia mensagens de estado para o ponto de estado de contingência

  • O cliente envia pedidos PXE para um ponto de distribuição com PXE ativado

  • O cliente envia dados de notificação para um ponto de gestão

Os pontos do Reporting Services estão configurados para utilizar HTTP ou HTTPS independentemente do modo de comunicação do cliente.

Quando utilizar o Gestor de configuração para implementar sistemas operativos com certificados autoassinados, um computador cliente terá de ter também um certificado para comunicar com o ponto de gestão, mesmo que se encontre numa fase transitória, por exemplo, a arrancar a partir de um suporte de dados de sequência de tarefas ou de um ponto de distribuição preparado para PXE. Para suportar este cenário para ligações de cliente HTTP, o Gestor de configuração gera certificados autoassinados com um identificador de objeto personalizado para assinatura e encriptação, sendo estes certificados utilizados para identificar o cliente de forma exclusiva. Para todos os sistemas operativos suportados exceto o Windows Server 2003, estes certificados autoassinados utilizam SHA-256 e têm um comprimento de chave de 2048 bits. Para o Windows Server 2003, é utilizado SHA1 com um comprimento de chave de 1024 bits. Se estes certificados autoassinados forem comprometidos, para impedir a sua utilização por atacantes para representar clientes fidedignos, bloqueie os certificados no nó Certificados da área de trabalho Administração, nó Segurança.

Quando os clientes ligam por HTTP, efetuam a autenticação dos pontos de gestão utilizando os Serviços de Domínio do Active Directory ou utilizando a chave de raiz fidedigna do Gestor de configuração. Os clientes não autenticam outras funções de sistema de sites, como pontos de migração de estado ou pontos de atualização de software.

Quando um ponto de gestão autentica pela primeira vez um cliente utilizando o certificado de cliente autoassinado, este mecanismo fornece uma segurança mínima porque qualquer computador pode gerar um certificado autoassinado. Neste cenário, o processo de identificação de clientes tem de ser aumentado mediante aprovação. Só devem ser aprovados computadores de confiança, quer automaticamente pelo Gestor de configuração, quer manualmente por um utilizador administrativo. Para mais informações, consulte a secção sobre aprovação em Comunicações Iniciadas por Clientes.