Active Directory, certificado de segurança de caractere curinga e acesso remoto

Question

Existe alguma maneira de proteger um domínio inteiro do Active Directory (AD) usando um único certificado de segurança curinga assinado por uma Autoridade de Certificação (CA) de terceiros para que o acesso remoto seja perfeito para:

1. RDP usando o Acesso via Web Remoto (RWA) via Gateway de Área de Trabalho Remota (RDG) para PCs.
2. RDP usando a Conexão de Área de Trabalho Remota via RDG (Remote Desktop Gateway) para o servidor RDS (Serviços de Área de Trabalho Remota).

Idealmente, eu gostaria que os usuários não recebessem avisos de certificados de segurança (independentemente de onde o computador estivesse ou se o computador estivesse ingressando no domínio) quando remotos por:

1. Navegando para https://internal.domain.com/remote , fazendo login e selecionando PC-01 .
2. Abrindo um RemoteApp e fazendo login.

Detalhes:

• Nome de domínio da Internet: domain.com
• Nome de domínio do AD: internal.domain.com
• Controlador de domínio AD e servidor RDG Nome de domínio totalmente qualificado: server-01.internal.domain.com
• Nome do domínio totalmente qualificado do servidor RDS: server-02.internal.domain.com
• Nome de domínio totalmente qualificado do PC: pc-01.internal.domain.com
• Certificado de segurança de curinga: *.internal.domain.com

Tanto quanto eu saiba, não pode ser feito como um único certificado de segurança só pode ser instalado em um único computador e este cenário exigiria que o certificado de segurança fosse instalado em 3 computadores (servidor RDG, servidor RDS e PC).

No entanto, sei que o AD tem sua própria infra-estrutura de chave pública (PKI) e CA "interna", que é usada para garantir a confiança entre seu domínio e os computadores associados a um domínio. Portanto, existe alguma maneira de substituir o certificado de segurança raiz da CA do AD pelo certificado de segurança curinga assinado pela CA de terceiros confiável?

Atualização 2016/06/30 16:33: Fiz um progresso significativo com isso e escreverei a resposta assim que os problemas tiverem sido corrigidos.

    

Answer 1

Aviso: Este é o melhor de minha lembrança

Nosso provedor de certificado de segurança, SSL247, me informou que os certificados de segurança de caractere curinga:

1. Cobrir apenas subdomínios um nível abaixo, não o domínio raiz.
2. Pode ser instalado em servidores ilimitados (também PCs?), a menos que sejam fornecidos pela Symantec (se bem me lembro).

Em termos simples, a resolução completa foi:

1. No servidor RDS, abra o Gerenciador RemoteApp e altere o RDG de internal.domain.com para remote.internal.domain.com .

2. Nos servidores de nomes autoritativos do domínio da Internet domain.com , crie o Registro de Recurso de DNS (RR):

   remote.internal.domain.com 3600 IN A <public IP address>

3. No roteador, crie regras de firewall e NAT para permitir e encaminhar a porta TCP 443 para o servidor RDG.

4. No servidor RDG, abra o Gerenciador do IIS e crie uma solicitação de assinatura de certificado (CSR) para *.internal.domain.com
5. Envie o CSR para a CA confiável de terceiros e espere pela emissão.
6. No servidor RDG, abra o Gerenciador do IIS, conclua o CSR instalando o certificado de segurança curinga e exporte o certificado de segurança curinga com sua chave privada para um arquivo PFX.
7. No servidor RDG, abra o Gerenciador de RDG e configure o certificado de segurança, as Diretivas de Autorização de Conexão (CAPs) e as Políticas de Autorização de Recurso (RAPs).
8. No servidor RDS, abra o MMC > Certificados e importe o arquivo PXF, instalando assim o certificado de segurança curinga.
9. No servidor RDS, abra a Configuração do host RDS e reconfigure a conexão "RDP-Tcp" alterando o certificado de segurança.

Na verdade, nossa resolução foi muito mais complicada.

Nossa configuração original foi a seguinte:

1. RDG de função instalado no servidor server-01.internal.domain.com executando o Windows Server 2012 R2 Essentials.
2. RDS de função instalado no servidor server-02.internal.domain.com executando o Windows Server 2008 R2 Standard.

Longa história curta (pedir esclarecimentos se necessário), esta configuração simplesmente não funcionou. Apesar de usar a conta de usuário administrativo do domínio e todas as configurações (RDG, CAPs, RAPs, NPS, etc.) serem configuradas como baixo / aberto possível, o RDP externo falhou consistentemente com os seguintes erros:

Remote Desktop can't connect to the remote computer "server-02.internal.domain.com" for one of these reasons:
1) Your user account is not authorized to access the RD Gateway "remote.internal.domain.com"
2) Your computer is not authorized to access the RD Gateway "remote.internal.domain.com"
3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)

Log Name: Microsoft-Windows-TerminalServices-Gateway/Operational
Source: Microsoft-Windows-TerminalServices-Gateway
Date: 2016/06/30 15:47:33
Event ID: 201
Task Category: (2)
Level: Error
Keywords: Audit Failure,(16777216)
User: NETWORK SERVICE
Computer: server-01.internal.domain.com
Description:
The user "%domainAdministrativeUserAccount%", on client computer "%ourPublicIPAddress%", did not meet connection authorization policy requirements and was therefore not authorized to access the RD Gateway server. The authentication method used was: "NTLM" and connection protocol used: "HTTP". The following error occurred: "23003".

Pesquisei bastante esse cenário e esses erros e encontrei uma boa quantidade de recursos, mas nenhum deles resolveu os problemas.

Eu investiguei o Network Operations Center (NOC) e eles concluíram que o problema foi causado pelo uso do Essentials.

Mudei o papel RDG do servidor # 1 para o servidor # 2 (percebo que isso é quase inútil), atualizei a rede e funcionou praticamente instantaneamente.

Oh, bem. Pelo menos funciona.