Local Certificates & Remote Desktop Services
I've been noticing some announcements like this one:
https://www.digicert.com/internal-names.htm
That certificates to internal hostnames can no longer be issued by trusted certificate authorities past X date. This is going to pose somewhat of an annoying issue for folks with Remote Desktop farms/deployments that utilize a gateway to access the session hosts behind it.
In the case where your internal DNS domain matches your external DNS domain, this doesn't matter, but there are plenty of folks who utilize a .local on the inside, which will be part of the connection broker address in a 2012 deployment for example. If you can't get a trusted certificate with an internal hostname, is the only solution to use an internal CA? Even if you do use an internal CA, you're still going to have to manually deploy the root certificate to external machines which is a complete mess.
Am I missing something?
https://www.digicert.com/internal-names.htm
That certificates to internal hostnames can no longer be issued by trusted certificate authorities past X date. This is going to pose somewhat of an annoying issue for folks with Remote Desktop farms/deployments that utilize a gateway to access the session hosts behind it.
In the case where your internal DNS domain matches your external DNS domain, this doesn't matter, but there are plenty of folks who utilize a .local on the inside, which will be part of the connection broker address in a 2012 deployment for example. If you can't get a trusted certificate with an internal hostname, is the only solution to use an internal CA? Even if you do use an internal CA, you're still going to have to manually deploy the root certificate to external machines which is a complete mess.
Am I missing something?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
One more question. At least in 2012, the Terminal Services environment needs to be on a Windows domain for it to even work, so if the back end session hosts are on the local domain so authentication can happen, how would you even be able to name them publically if you are tied to the potential .local domain that the rest of your resources are on?
RDS machines do not need to be domain joined, even in 2012. Some functionality is exposed in server manager only via domain joined machines, but in general for machines in a DMZ, I recommend group policy anyways. It is more systematically scalable and enforceable than GUI configurations which, by the fact it is a GUI, cannot be easily automated.
With that said, if you really wanted to, a second domain can be set up and a trust created to handle authentication. That provides isolation of the RDS environment, centralized control, but single authentication possibilities (including ADFS, MFA, etc.) In some larger deployments, this is a preferred scenario.
So you have options.
With that said, if you really wanted to, a second domain can be set up and a trust created to handle authentication. That provides isolation of the RDS environment, centralized control, but single authentication possibilities (including ADFS, MFA, etc.) In some larger deployments, this is a preferred scenario.
So you have options.
ASKER