So I have googled my way again (did the same about a year ago) and haven't found any updated information regarding the possibility of setting up RDS 2012 R2 services with the RDGateway/RDWeb access role/server located in a DMZ. All the information regarding setup of RDS seems to point to Windows Server 2008, with most people citing that this information still applies to Server 2012 R2. I am speaking particurlaly about this Remote Desktop Services Blog post (http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx). This post talks about three sections with a DMZ (3.1,.3.2 and 3.3).
The way I read 3.1 is that it is talking about the server in the DMZ being domain joined to the internal corp domain and then having open ports back to the DCs, Other RDS servers and resources. In practical terms I cant see the point of having this server in the DMZ in this case.
The second and third scenarios deal with trusts between the domain in the DMZ and the internal corp domain. I currently am using the 3.3 scenario with a RODC and extended corp trust, but have been running into issues with the RODC. There is nothing wrong with the function of it, but the practice of using a RODC for the RDSweb/RDGateway authentication in the DMZ does not allow for offsite users to change their password when it is required. I have about 20 users who are now exclusively remote in operation and this is presenting a problem without allowing a way for them to correct it themselves.
The scenario for 3.2 deals with what I believe would be a solution for my problem. In my thinking, the trust would allow the users to update their passwords (as would scenario 3.1 but I would fail a security audit if I allowed those ports required to be open). I have been setting up scenario 3.2 and have been running into all kinds of problems. The problems seem to be specific to Server 2012 R2 RDS setup as the setup of RDS is expecting to have unencumbered normal domain access to all the servers involved when establishing the roles. I currently have things (for testing) as open as they could in this scenario, full two way trust between the two domains (forest-wide authentication), all ports open between the server in the DMZ and it's RDS role counterparts on the internal domain. In this configuration it succeeds installing the RDWeb and RDGateway roles. When trying to install the roles with a one way trust, the setup process kept failing as it wants to add the computer account (of the DMZ server it cant see in this one way trust scenario) to a local group on the connection broker server.
What I am curious to know is -
-Will having a trust in place allow users to change their password on RDWeb? I assume that the DMZ DC just acts as a proxy to the internal DCs if it does.
-Has anyone actually been able to setup a one way trust with Server 2012 R2 RDS with the RDWeb/RDGateway server in the DMZ? I can start to work backwards from where I have things configured now and try to get this to work with a one way trust, but if anyone knows why it is not possible it would save me a lot of time.
-If this scenario with a one way trust isnt possible, is there any way of using a two way trust with selective authentication to further reduce the risks of that trust (only including computer accounts, user accounts etc that need to be included for the RDS function)?
Thanks,
Brian