That is why we recommend that the Subject Alternate Name for the certificate contain the names of all the servers that are part of the deployment. The certificate can be common on all of these servers. So in this example, “.” But the connection does not end there – the connection flows from the web server to one of the session hosts or virtualization hosts and also to the connection broker. The name of the certificate needs to be the same as the URL. When clients connect internally, they enter the FQDN for the server that hosts the web page, for example,. Virtualization host with VDI VMs configured For Single Sign On, the subject name needs to match the servers in the collection.įor example, imagine a Remote Desktop deployment with the following computers: If you have users connecting internally to RDWeb, the name needs to match the internal name. If you have users connecting externally, this needs to be an external name (it needs to match what they connect to). The certificate for RDWeb needs to contain the FQDN or the URL, based on the name the users connect to. For example, for Publishing, the certificate needs to contain the names of all the RDSH servers in the collection.
The certificates you deploy need to have a subject name or subject alternate name that matches the name of the server that the user is connecting to.
#SERVER 2016 REMOTE DESKTOP CAL BYPASS WINDOWS#
In Windows 2012, you connect to the connection broker, and it then routes you to the collection by using the collection name. In Windows 2008 and Windows 2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, then to the connection broker, and finally to the server that hosts your session. If you are going to let users to connect externally, and they are not part of your AD domain, you need to deploy certificates from a public CA, such as GoDaddy, Verisign, Entrust, Thawte, or DigiCert. You can request and deploy your own certificates, and they will be trusted by every computer in the AD domain. The easiest way to get certificates, if you control the client computers, is by using Active Directory Certificate Services. When you open the new certificate, the General tab of the certificate will list the purpose as “Server Authentication.” You can validate that the certificate was created in the Certificates MMC snap-in.
Select Client-Server Authentication, and then click OK. In the certsrv snap-in right-click Certificate Templates, and then click New > Certificate Template. Click OK, and then close the Certificates Templates console. On the Security tab, select Allow Autoenroll next to Domain Computers. Click OK until you get back to the Properties page. Click Add, and then select Server Authentication. On the Extensions tab, click Application Policies > Edit. On the General tab, change the Template display name to Client Server Authentication, and select Publish certificate in Active Directory. Right-click Workstation Authentication, and then click Duplicate Template. Right-click Certificate Templates, and then click Manage. In the Details pane, expand the computer name. Open CERTSRV.MSC and configure certificates. Here are the steps for creating the Server Authentication certificate from the template: You can use the Workstation Authentication template to generate this certificate, if necessary. You can also use certificates with no Enhanced Key Usage extension.Ĭreate a Server Authentication certificateĪs the name suggests, a Server Authentication certificate is required. The Enhanced Key Usage extension has a value of either “Server Authentication” or “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). The certificate has a corresponding private key. The certificate is installed in the local computer’s “Personal” certificate store. As long as the client trusts the server it is communicating with, the data being sent to and from the server is considered secure.Ĭertificates in Remote Desktop Services need to meet the following requirements: When a communication channel is set up between the client and the server, the authority that generates the certificates vouches that the server is authentic. Using certificates for authentication prevents possible man-in-the-middle attacks. When a client connects to a server, the identity of the server and the information from the client is validated using certificates. Remote Desktop Services uses certificates to sign the communication between two computers.
0 kommentar(er)
