Questions

External Remote Desktop Gateway/RDWeb

+
0 Votes
Locked

External Remote Desktop Gateway/RDWeb

jfuller05
Alright fellow techies here's the rundown. I have installed Server 2008 r2 Remote Dekstop Services on a VM in my network. I installed the following RD role services: RD Session Host, Licensing, Connection Broker, Gateway, Web Access. When I set things up originally, the gateway server and RDWeb worked as it should locally. After getting things running locally (remoteserver.domainname.local) I wanted to test things externally. From the outside, I couldn't get things running (meaning I could connect to rdweb access externally, but when I tried to run an app I would get the message "can't connect/find computer"). Here's my setup for external access

NOTE: The VM has every RD Services role services installed on it, meaning it acts as gateway, rd web access, session host, licensing, the whole bit.

-I made a self-signed certificate on the gateway server (gateway.domainname.net is the cert name). Internally, I have a secondary forward-lookup zone called domainname.net with an A record gateway pointing to the local IP of the gateway server. On our public DNS (domainname.net) I have an A record gateway. This is to access the RDWeb externally.

-In IIS I have the following authentication settings RDWeb: All disabled except for anonymous authentication Rpc: All disabled except for basic and windows RpcWithCert: All disbled except for windows authentication

-I have the necessary web access config in our sonicwall tz210 (https and rdp, external ip pointing to local ip of rds server)

-RAP and CAP have the correct user and computer groups, authentication, and allowed devices

After all of this, here's what happens accessing externally. I can login correctly to RDWeb Access (I've tried a bogus login, I can't login to it so that's working properly). I see the Apps for use. I click on an app, click connect, the credential window opens, I put in the correct user creds, it tries to connect to the gateway server, but then the cred window comes back in view. I tried to reach a limit of failed logins, but never reached one, haha.

So from the same external client machine I try to connect to the gateway through a Remote Desktop connection. I put in the correct gateway settings in the RD window, try to connect and get the same results as I did in RDWeb access.

I checked the event logs on the RD Services machine and saw the following event IDs around the time I tried to login externally:

ID 6037 with the message "The program svchost.exe, with the assigned process ID 2168, could not authenticate locally by using the target name host/gateway.domainname.net. The target name used is not valid. A target name should refer to one of the local computer names, for example, the DNS host name. Try a different target name."

ID 10 RADWebAccess "RD Web Access was unable to access gateway.domainname.net, which is the server that is specified as running the RemoteApp and Desktop Connection Management service. Ensure that the computer account of the RD Web Access server is a member of the TS Web Access Computers security group on gateway.domainname.net"

ID 4625 "An account failed to log on.

Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed: Security ID: NULL SID Account Name: Administrator Account Domain: gateway.domainname.net

Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xc000006d Sub Status: 0xc000006a

Process Information: Caller Process ID: 0x0 Caller Process Name: -

Network Information: Workstation Name: USER-LAPTOP Source Network Address: External IP Source Port: 63125

Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols."

I don't think the VM has a null SID. The SID of the VM and it's physical host have different SIDS. I can access the blank page for rpc externally using the external gateway name.

It seems like authentication is a problem. Also, is it a problem that the external name of the gateway server doesn't match the local name? The external name (which the cert is based on) is gateway.domainname.net and the internal name is remoteserver.domainname.local. That's the only thing I can think of that would be the problem, but the external name has to be different from the local right? Internally, I ping gateway.domainname.net and it gives me the correct local IP of the server. Now, there isn't an actual computer name in AD, but I don't know how I would achieve that?

I hope I've been clear....any help would be appreciated. I think I'm close to achieving this. :)
  • +
    1 Votes
    robo_dev

    the FQDN in the cert has to match the FQDN of the server, period. (or that would not be terribly secure otherwise). I have not ever

    used a wildcard cert, but I think that might help here.

    social DOT technet DOT microsoft DOT com/Forums/en-US/winserverTS/thread/23c58ea5-1c2d-4129-b609-58110e3e7295/

    Weird permission things to look at:

    Check if the "TS Web Access Computers" security group on the RDSH server has incorrect permissions in DCOM and/or WMI:

    social DOT technet DOT microsoft DOT com/Forums/en/winserverTS/thread/173d4546-e12f-47c1-ac66-8b4f69826892

    +
    0 Votes
    jfuller05

    Thanks for the suggestions Robo_dev I apologize for just now responding. I forgot that I posted the question here.

    We aren't working on the problem anymore. People agreed to just go with VPN even though RDWeb would be much more efficient I think.

    I'm going to look into these articles and work on this in my spare time.

    Thanks again!

    +
    0 Votes
    Jmurray0404

    I know this is an old thread but since I was able to find it I am sure others will.
    This sounds like the same problem I was having. When I would login to the RDWeb service I could see the apps but once I tried to open them I got the "cannot find/connect to computer" error.
    The problem was that on the RD Gateway I entered the FQDN in the server name area instead of the name that the DNS had on record.
    I entered (servername.domainname.com) instead of (servername).

    Hope this helps anyone that finds this thread.

  • +
    1 Votes
    robo_dev

    the FQDN in the cert has to match the FQDN of the server, period. (or that would not be terribly secure otherwise). I have not ever

    used a wildcard cert, but I think that might help here.

    social DOT technet DOT microsoft DOT com/Forums/en-US/winserverTS/thread/23c58ea5-1c2d-4129-b609-58110e3e7295/

    Weird permission things to look at:

    Check if the "TS Web Access Computers" security group on the RDSH server has incorrect permissions in DCOM and/or WMI:

    social DOT technet DOT microsoft DOT com/Forums/en/winserverTS/thread/173d4546-e12f-47c1-ac66-8b4f69826892

    +
    0 Votes
    jfuller05

    Thanks for the suggestions Robo_dev I apologize for just now responding. I forgot that I posted the question here.

    We aren't working on the problem anymore. People agreed to just go with VPN even though RDWeb would be much more efficient I think.

    I'm going to look into these articles and work on this in my spare time.

    Thanks again!

    +
    0 Votes
    Jmurray0404

    I know this is an old thread but since I was able to find it I am sure others will.
    This sounds like the same problem I was having. When I would login to the RDWeb service I could see the apps but once I tried to open them I got the "cannot find/connect to computer" error.
    The problem was that on the RD Gateway I entered the FQDN in the server name area instead of the name that the DNS had on record.
    I entered (servername.domainname.com) instead of (servername).

    Hope this helps anyone that finds this thread.