1

Is there any way to secure an entire Active Directory (AD) domain using a single trusted, third-party Certification Authority (CA)-signed wildcard security certificate so that remote access will be seamless for:

  1. RDP using Remote Web Access (RWA) via Remote Desktop Gateway (RDG) to PCs.
  2. RDP using Remote Desktop Connection via Remote Desktop Gateway (RDG) to Remote Desktop Services (RDS) server.

Ideally, I'd like it so that the users get no security certificate warnings (regardless of the where the computer is or whether the computer is domain-joined) when remoting in by:

  1. Browsing to https://internal.domain.com/remote, signing in, and selecting PC-01.
  2. Opening a RemoteApp and signing in.

Details:

  • Internet Domain Name: domain.com
  • AD Domain Name: internal.domain.com
  • AD Domain Controller and RDG server Fully Qualified Domain Name: server-01.internal.domain.com
  • RDS server Fully Qualified Domain Name: server-02.internal.domain.com
  • PC Fully Qualified Domain Name: pc-01.internal.domain.com
  • Wildcard security certificate: *.internal.domain.com

As far as I'm aware, it cannot be done as a single security certificate can only be installed on a single computer and this scenario would require the security certificate to be installed on 3 computers (RDG server, RDS server, and PC).

However, I know that AD has its own Public Key Infrastructure (PKI) and "internal" CA which is used to ensure trust between its domain and domain-joined computers. So, is there any way to replace AD's CA root security certificate with the trusted, third-party CA-signed wildcard security certificate?

Update 2016/06/30 16:33: I have made significant progress with this and will write up the answer once the problems have been fixed.

0

Disclaimer: This is to the best of my recollection

 

Our security certificate provider, SSL247, informed me that wildcard security certificates:

  1. Only cover subdomains one level down, not the root domain.
  2. Can be installed on unlimited servers (also PCs?), unless they're provided by Symantec (if I recall correctly).

 

In simple terms, the full resolution was to:

  1. On the RDS server, open RemoteApp Manager and change the RDG from internal.domain.com to remote.internal.domain.com.
  2. On the Internet domain domain.com's authoritative name servers, create the DNS Resource Record (RR):

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

  3. On the router, create firewall and NAT rules to allow and forward port TCP 443 to the RDG server.

  4. On the RDG server, open IIS Manager and create a Certificate Signing Request (CSR) for *.internal.domain.com
  5. Submit the CSR to the trusted, third-party CA and wait for issuance.
  6. On the RDG server, open IIS Manager, complete the CSR thereby installing the wildcard security certificate, and export the wildcard security certificate with its private key to a PFX file.
  7. On the RDG server, open RDG Manager and configure the security certificate, Connection Authorization Policies (CAPs), and Resource Authorization Policies (RAPs).
  8. On the RDS server, open MMC > Certificates and import the PXF file thereby installing the wildcard security certificate.
  9. On the RDS server, open RDS Host Configuration and reconfigure the connection "RDP-Tcp" changing the security certificate.

 

In actuality, our resolution was a lot more complicated.

Our original setup was as follows:

  1. Role RDG installed on server server-01.internal.domain.com running Windows Server 2012 R2 Essentials.
  2. Role RDS installed on server server-02.internal.domain.com running Windows Server 2008 R2 Standard.

Long story short (ask for clarification if required), this setup just did not work. Despite using the domain administrative user account and all settings (RDG, CAPs, RAPs, NPS, etc) being configured as low / open as possible, external RDP failed consistently with the following errors:

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".

I heavily researched this scenario and these errors and found a fair amount of resources but none resolved the problems.

I had our Network Operations Center (NOC) investigate and they concluded that the problem was caused by the use of Essentials.

I moved the role RDG from server #1 to server #2 (I realise this is nearly pointless), updated the network, and it worked pretty much instantly.

Oh, well. At least it works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.