2

We recently reissued our GoDaddy wildcard cert with the SHA256 signing algorithm (FYI they still revoke the old cert in 72 hours even if you don't re-key it, so you should re-key anyway). We use this cert for our RemoteApps, Terminal Servers' RDP, RDGateway, and RDWeb (IIS).

When I change to the new wildcard certificate in the "RemoteApp Manager"->"Digital Signature Settings" on a given Terminal Server (AKA Session Host server) Connections from RDWeb for apps published on that terminal server fail for some users, but connections using the a .rdp file work fine for all users. Furthermore, and this is the strangest thing I have ever seen, the wrong user is logged as being denied access at the gateway. If I change the certificate back to the old, revoked cert for this one setting, then everything works.

Working Setup:

  • All Windows 2008 R2 Datacenter servers
  • RDGateway+RDWeb - rdsgateway.contoso.com (new wildcard cert installed for both IIS and rdgateway)
  • TS - ts1.contoso.com (new wildcard cert installed only for RDP, OLD cert installed for RemoteAPP)

Non-working Setup:

  • All Windows 2008 R2 Datacenter servers
  • RDGateway+RDWeb - rdsgateway.contoso.com (new wildcard cert installed for both IIS and rdgateway)
  • TS - ts1.contoso.com (new wildcard cert installed for RDP, NEW cert installed for RemoteAPP) non-working RemoteApp configuration

When Launching from RDWeb using user "CONTOSO\bob" the following error is generated:

Remote Desktop can't connect to the remote computer "ts1.contoso.com" for one of these reasons: 1) Your user account is not listed in the RD Gateway's permission list 2) you might have specified the remote computer in NetBIOS format...

Client Connection Error

When I look at the Event log "Microsoft-Windows-TerminalServices-Gateway/Operational" I see the following error:

The user "CONTOSO\alice", on client computer "123.123.123.123", did not meet resource authorization policy requirements and was therefore not authorized to resource "ts1.contoso.com". The following error occurred: "23002".

What is going on? Why does changing the RemoteApp's signing cert cause the gateway to think this is a different user connecting?

  • I thought that by disabling and re-enabling the particular Resource Authorization Policy (RAP) on the gateway server, the remoteapp now functions normally and the correct user is logged, but does not appear to be the case. This is still highly concerning that the wrong user would be logged/denied access at the gateway server based upon a certificate change of a published RemoteApp on the terminal server. – BrianCanFixIT Jan 27 '15 at 3:30
1

Found this page after experiencing the same problem. For us the solution was to add port 3389 to loopback (aka Hairpin NAT) on our firewall.

Some additional detail:

Replacing the certificate was trickier than installing it the first time, but I think we did it correctly, and apps worked fine for a day or two. Users started getting errors on launch, and we wound up using the powershell script here https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80 to re-publish the FQDN of the server.

I think this script must have set the FQDN in a part of the config that had never been specified before, causing the RD Gateway to refer to itself by its FQDN to hand off requests. These requests failed as our edge firewall allowed only 80 and 443 for both incoming and loopback requests.

Adding port 3389 to the loopback rule on the firewall resolved the problem immediately.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.