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?
LVL 4
jschwegAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
Nope.  You aren't missing anything.  RDS is going to be one significant pain point for these types of environments.  Exchange? No problem.  Lync (now Skype for business?)  Easy.  Those services have long since supported alternate URLs and things like DNS SRV records to map external resources to internal machines.  Oddly RDS never took that route.  You can fix up RDWeb and RDGateway, but internal machines, not so much.  There are a few WMI hacks, but they have significant downsides.

With that said, I will say I think one of the better solutions given our current threat assessment is that machines where public access is going to occur, such as RDS machines from the outside world, should probably live in an isolated network anyways, with only pinhole access to resources on the LAN.  And as long as you are doing that, making RDS servers with public names from the get-go becomes a real possibility and will be more serviceable moving forward. It is not dissimilar to the approach Microsoft is taking with Azure RemoteApp. That's basically a RemoteApp RDS deployment that you can connect to private resources on the LAN over a secure site-to-site link. And their RDS deployment doesn't use your internal name when you make such a setup.

The up front architecture will be a learning curve and take some effort, but the end results will be scalable well into the future. In most cases, that's my recommendation.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jschwegAuthor Commented:
Argh. That is so hopelessly annoying. Thanks for confirming it.
jschwegAuthor Commented:
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?
Cliff GaliherCommented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.