Microsoft Remote Desktop For Mac App Updated Password Expired

-->

Now that you have created your certificates and understand their contents, you need to configure Remote Desktop to use those certificates. On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane. Click Tasks Edit Deployment Properties. In the Configure the deployment window, click Certificates. Before you go. Leave your email so that you can share your thoughts about this app with the entire MacUpdate community! You’ll help others find the apps they need and earn some karma points for yourself.

Remote Desktop Services uses certificates to sign the communication between two computers. When a client connects to a server, the identity of the server and the information from the client is validated using certificates.

Using certificates for authentication prevents possible man-in-the-middle attacks. 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. As long as the client trusts the server it is communicating with, the data being sent to and from the server is considered secure.

Certificates in Remote Desktop Services need to meet the following requirements:

  • The certificate is installed in the local computer’s “Personal” certificate store.

  • The certificate has a corresponding private key.

  • 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). You can also use certificates with no Enhanced Key Usage extension.

Create a Server Authentication certificate

As the name suggests, a Server Authentication certificate is required. You can use the Workstation Authentication template to generate this certificate, if necessary.

Here are the steps for creating the Server Authentication certificate from the template:

  1. Open CERTSRV.MSC and configure certificates.

  2. Open the Certificate Authority.

  3. In the Details pane, expand the computer name.

  4. Right-click Certificate Templates, and then click Manage. Right-click Workstation Authentication, and then click Duplicate Template.

  5. On the General tab, change the Template display name to Client Server Authentication, and select Publish certificate in Active Directory.

  6. On the Extensions tab, click Application Policies > Edit. Click Add, and then select Server Authentication. Click OK until you get back to the Properties page.

  7. On the Security tab, select Allow Autoenroll next to Domain Computers. Click OK, and then close the Certificates Templates console.

  8. In the certsrv snap-in right-click Certificate Templates, and then click New > Certificate Template.

  9. Select Client-Server Authentication, and then click OK.

You can validate that the certificate was created in the Certificates MMC snap-in. When you open the new certificate, the General tab of the certificate will list the purpose as “Server Authentication.”

The easiest way to get certificates, if you control the client computers, is by using Active Directory Certificate Services. You can request and deploy your own certificates, and they will be trusted by every computer in the AD domain.

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.

Certificate contents

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.

Microsoft Remote Desktop For Mac App Updated Password Expired Iphone

In Windows 2012, you connect to the connection broker, and it then routes you to the collection by using the collection name.

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. For example, for Publishing, the certificate needs to contain the names of all the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN or the URL, based on the name the users connect to. If you have users connecting externally, this needs to be an external name (it needs to match what they connect to). If you have users connecting internally to RDWeb, the name needs to match the internal name. For Single Sign On, the subject name needs to match the servers in the collection.

For example, imagine a Remote Desktop deployment with the following computers:

Computer name

Description

RDSH.CONTOSO.COM

Session Host with RemoteApp configured

RDSH2.CONTOSO.COM

Session Host with RemoteApp configured

RDVH1.CONTOSO.COM

Virtualization host with VDI VMs configured

RDVH2.CONTOSO.COM

Virtualization host with VDI VMs configured

RDCB.CONTOSO.COM

Connection Broker

RDWEB.CONTOSO.COM

RDWeb and Gateway server

When clients connect internally, they enter the FQDN for the server that hosts the web page, for example, RDWEB.CONTOSO.COM.

The name of the certificate needs to be the same as the URL. So in this example, “RDWEB.CONTOSO.COM.” 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 certificate can be common on all of these servers. 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.

Microsoft Remote Desktop For Mac App Updated Password Expired Windows 10

So the certificate for our example deployment would contain:

Type: Server Authentication

Name: RDWEB.CONTOSO.COM

SAN: RDSH1.CONTOSO.COM; RDSH2.CONTOSO.COM; RDVH1.CONTOSO.COM; RDVH2.CONTOSO.COM; RDCB.CONTOSO.COM

This certificate approach works as long as you have five or fewer servers in your deployment. If you have more servers, you can’t use the Subject Alternate Name field (it is limited to just five servers). Instead, you need to get a wildcard certificate to cover all the servers in the deployment.

A wildcard certificate for our example deployment would contain:

Type: Server Authentication

Name: RDWEB.CONTOSO.COM

SAN: *.CONTOSO.COM

Even with a wildcard certificate, you might run into problems in the following scenario if you have external users that access the deployment:

External name: RDWEB.CONTOSO.com

Internal name: RDWEB.CONTOSO.local

If you have a certificate with RDWEB.CONTOSO.COM in the name, you will see certificate errors. This is because the certificate is supposed to validate a server with the FQDN of “RDWEB.CONTOSO.COM,” but your server name is “RDWEB.CONTOSO.local.” (Changing the .com to .local occurs at your public firewall or router using port forwarding.)

In this case, you can get a certificate from a public CA with the external name (RDWEB.CONTOSO.COM) and bind it to the RD Web Access and RD Gateway roles. (These are the only roles that are exposed to the Internet.) For the RD Connection Broker – Publishing and RD Connection Broker – Enable Single Sign On roles, you can use an internal certificate with the DOMAIN.local name on it. However, be aware that this only works if your clients are connecting through RDC 8.0 or later.

The RD Gateway and Remote Desktop Client version 8.0 (and later) provides external users with a secure connection to the deployment. Once connected to the deployment, the internal certificate with the ‘.local’ name will take care of RemoteApp signing (publishing) and Single Sign On.

Selecting which certificate to use

Now that you have created your certificates and understand their contents, you need to configure Remote Desktop to use those certificates.

Microsoft Remote Desktop For Mac App Updated Password Expired Windows 7

  1. On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane.

  2. Click Tasks > Edit Deployment Properties.

  3. In the Configure the deployment window, click Certificates.

  4. Click Select existing certificates, and then browse to the location where you saved the certificate you created previously. Look for the file with the .pfx extension.

  5. Import the certificate.

    You can use a single certificate for all the roles if your clients are internal to the domain only, by generating a wildcard certificate (*.CONTOSO.local) and binding it to all roles.

    Note that, even if you have multiple servers in the deployment, Server Manager will import the certificate to all servers, place the certificate in the trusted root for each server, and then bind the certificate to the respective roles.

I think you are out of luck, I don;t think you can download it from anywhere else.

Maybe also look into http://cord.sourceforge.net

Why don't you try downloading it on your computer and see if you can extract the file from the download? Right-click and show package content.

PS: Is that: https://www.microsoft.com/en-us/download/details.aspx?id=465 the right client?
I can't test it since I don't have a MAC at work.

or this one: https://www.microsoft.com/en-us/download/details.aspx?id=18140

Section 1.3 applies to your use of other services that may be made available for use through your use of the Software. Updates.Notwithstanding above Section 1.1 as applied to Windows 7, 8, and 8.1, the terms of the applicable Windows License Terms, or any Windows update settings you have configured, the Software periodically checks for updates, and downloads and installs them for you. If the Software is downloaded from Microsoft and labeled preview, insider, beta or pre-release, or is otherwise indicated as not being a final retail version of the Software, the applicable terms in Section 1.2 also apply to your use of the Software. Your installation and use of the Software on any Windows platform shall be governed by the license terms for your Microsoft Windows Operating System software (“Windows License Terms”) on which you are using the Software, and those terms are incorporated by reference. Windows License Terms. Microsoft

Edited Apr 21, 2015 at 22:53 UTC