locked
terminal server Certificate RRS feed

  • Question

  • Hi,

    I have a question about the way the remote desktop certificates are handled.

    I have a multi tenant setup with child domains. Every tenant has access to their own terminal server. The tenants login to the uag portal, where they can click on their remote desktop icon. When clicked the remote desktop web client sees it has to travel trough the UAG's buildin ts gateway (name.domain.com) which has a valid certificate in place. However all users are confronted with a certificate warning that comes from the Remote desktop server (TS.child.domain.com) behind the UAG.

    I was in the understanding that only the TS gateway certificate should be valid and trusted and that it would not matter what certificates are behind that gateway.

    Best regards,

     

    Ruud Boersma


    MSCE
    Monday, October 31, 2011 9:23 AM

Answers

  • Hi Ruud,

    "Internally you connect to the terminal servers fqdn. This fqdn matches the Common name on the certificate. That's why you do not get the warning. If you access from the internet you connect to the UAG portals fqdn, which has a certificate with a common name that matches the UAG internet fqdn."

    When connecting from outside, the browser connects to the UAG with the UAG portal's fqdn, etc. But after the user access the TS icon on the portal, the mstsc client is connecting to the backend TS server's fqdn (as definied in the UAG configuration). So it is not the "When the user is authenticated, it should be able to start his/her apps without any warning" because the check now is done by the mstsc client against the backend ts server, so if the certificate is not trusted, it will fail. You can see that if you install the backend certificate on the client as trusted, you should not get this warning.

    There is nothing wrong with this design, because the connection eventually is between the client and the backend server. The UAG just "open the gate" to allow the connection and it verify the client is authenticated correctly and protected, but when the client connet, it needs to verify the server and this is where you get the warning. The client trust the gateway but it does not mean it trust the backend application.

    It is also different protocols in this game - the client connect to the UAG using HTTPS but to the TS Server using RDP. The fact the HTTPS connection was validated does not mean the RDP protocol also secured. 

    Ophir.

    • Marked as answer by Ruud Boersma Thursday, November 3, 2011 8:08 AM
    Thursday, November 3, 2011 7:13 AM

All replies

  • Hi Ruud,

    Can you confirm what exactly warning the users are getting?

    If you get warning similar to the following:

    Then this is not coming from the backend server. This warning is because the UAG is using RDP file, and it sign that file using the server certificate in the UAG's IIS. The warning is about the signature of the RDP and not coming from the backend server.

    If you are getting different warning, please send a screenshot.

    Thanks,

                     Ophir.

    Monday, October 31, 2011 2:17 PM
  • Hi Ophir,

     

    Thanks for replying.

    It's not this one. It 's the certificate warning that comes after the screen you provided, after typing the login credentials.


    MSCE
    Tuesday, November 1, 2011 6:32 AM
  • Hi Ruud,

     

    I think I was mistaken the RemoteApp scenario with the Remote Desktop.

    It sound the warning you get is due to the MSTSC authentication checking, can you play with this on the client and see if this make difference:

    If so - this is because the client check the backend server so this is client to back-end server issue regardless of the gateway.

     

    Ophir.

    Tuesday, November 1, 2011 9:39 AM
  • Hi,

     

    If I set it, on the client side, to connect and do not warn. The cert. warning still pops up. So this does not do the trick. Which is fine, since I cannot manage the client side. I´m afraid I have to buy a wildcard certificate to place on all terminal servers.


    MSCE
    Tuesday, November 1, 2011 2:20 PM
  • Hi Ruud,

    I just tried to access regular server with regular RDP session (MSTSC):

    - If I access using the FQDN - No error

    - If I access using the netbios name - No error

    - If I access using the IP address - I get the exact error you get, with warning the certificate is not from a trusted CA (the certificate is selfsigned certificate that was generated automatically by the RDP service).

    In my case, however, when I set the client to connect with no warning, I don't get the warning.

     

    I think you should do the same test with your backend server, as it seems you don't need "real" certificate, just self-signed certificate that match the server name.

    You can try also play with the following settings on the RD Session host:

     

    I also recommend to launch MSTSC on the UAG itself as a client to your backend server and see if you do not get any errors.

    I can also be CRL issue or something similar (i.e. UAG fail to check CRL for the certificate and this cause the error).

     

    Ophir.

    Tuesday, November 1, 2011 4:43 PM
  • Hi,

     

    I allready tried placing the GW certificate (name.domain.com) on the TS. If they access the UAG The customer goes to the fqdn name.domain.com. The terminal server in the backend is named a.child.domain.com. If I place the certifcate name.domain.com on that TS i'll also get the cert. warning. Which is logical, because the common name does not match. It matches just the TS GW's name.

     

    EDIT: directly from UAG is succesfull, because i'm then connecting to the inside fqdn a.child.domain.com. The customer however connects to the UAG from the internet. The GW should connect to the inside FQDN, but for some reason it's transfers the certofocate form the inside server to the client which is on the internet. That results in the warning. Maybe it's by design, I do not know.

     

    EDIT2:Check this:

    http://technet.microsoft.com/en-us/library/dd857385.aspx

    the last step exactly says what I was thinking how it would work. The question remains: Why is the endpoint client confronted with the backend remote desktop session hosts certificate?


    MSCE

    • Edited by Ruud Boersma Wednesday, November 2, 2011 9:44 AM
    Wednesday, November 2, 2011 6:26 AM
  • Hi Ruud,

     

    One think I do not understand, you are saying the customer, when accessig from outside, use the TS GW name.

    I think this is wrong. It seems you expect the gateway to do proxy (i.e. client connect to gw and gw connect to backend) but this is not how it works. The GW just "tunnel" the request and does not proxy it.

    So there are two parts:

    1. Client connect to the GW and create a tunnel.

    2. Client use that tunnel to connect to the backend.

    For each part you have different hostname and matching certificate (the gateway have certificate for the GW host, and the backend should have certificate for the backend host).

    Can you try use the a.child.domain.com address from the client, even when you are accessing from the internet, and see if you still get the warning ?

    You can also see in the screenshot I sent for the RemoteApp (few posts up) that the client aware that "Gateway server" and "Remote computer" are two different names.

     

    Ophir.

    Wednesday, November 2, 2011 9:45 AM
  • I understand. But the link i placed above says the client connects to the gateway. Then the gateway connects to the backend server (step 7), there is no mention that it tunnels right trough.

    In the end it means that I need a wildcard certificate to place on alle terminal server in the child domain from a public CA. That's not a problem, I just wanted to be sure that the problem was not due to misconfiguration.

     


    MSCE
    Wednesday, November 2, 2011 11:46 AM
  • Hi Ruud,

    This may be a semantic issue.

    Even when using a tunnel, the UAG need to connect to the backend server, but my point it does not proxy the connection, but just pass the connection (but I may be wrong).

    Did you manage to do the test I asked:

    "Can you try use the a.child.domain.com address from the client, even when you are accessing from the internet, and see if you still get the warning ?"

    If this works, this may prove my theory...

    Ophir.

    Wednesday, November 2, 2011 11:54 AM
  • Hi Ophir,

    Can you try use the a.child.domain.com address from the client, even when you are accessing from the internet, and see if you still get the warning ?"

    That is exactly what I do when i get the certificate warning. The client starts internet explorer and travels to name.domain.com (which is the UAG portal). The client logs on. The client clicks the application icon that connects the client to the remote desktop. The application, which is a UAG remote desktop (predefined) object, has the server setting a.child.domain.com. The client is confronted with the popup:

    the client clicks connect (verbinden) and then is confronted with a login.

    After the client logs in he/she gets the certificate warning:

    this is de default remote desktop sessions servers certificate.

     


    MSCE
    • Edited by Ruud Boersma Wednesday, November 2, 2011 12:47 PM
    Wednesday, November 2, 2011 12:46 PM
  • Hi Ruud,

    Ok. This is much more clear now.

    So could it be as simple as trust CA issue? The error you get mention CA trust. Can you just place the a.child.domain.com certificate (which I assume it is self-signed if it is the default one) in the client's trusted CA store and see if you still get the warning?

    If it is not self-signed certificate, can you place the CA that issue that certificate in the client trusted CA store?

     

    EDIT: And btw, wildcard certificate will not help you here, because *.domain.com is invalid for a.child.domain.com ... 

     

    Ophir.


    Wednesday, November 2, 2011 1:01 PM
  • I know, but I mentioned *.child.domain.com.

    I also know it is not trusted. Like I said the certificate that's placed on the RD GW ,name.domain.com, is a trusted certificate. I thought that would be enough. Apparently it's not, and the certificate at the TS also needs to be trusted. Like you said, the GW is tunneling not Proxying.

    I'll buy a wildcard from a trusted CA for *.child.domain.com and that wil solve my "problem".


    MSCE
    Wednesday, November 2, 2011 2:49 PM
  • I just tested in lab, and indeed, if the backend TS use a certificate that is not trusted by the client (even with correct name), you will get this warning.

    If you access the same TS internally (not from outside) you will not get the warning if the name on the certificate match the name you specificied (even if you do not trust the cert's issuer), so it seems that internally there is another mechanism to validate the server identity but from outside it relay on the certificate trust checking...

    Wednesday, November 2, 2011 3:23 PM
  • Internally you connect to the terminal servers fqdn. This fqdn matches the Common name on the certificate. That's why you do not get the warning. If you access from the internet you connect to the UAG portals fqdn, which has a certificate with a common name that matches the UAG internet fqdn.

    I still think that that should be enough. Security and validation should be done by the UAG, not again by the servers (terminal servers) that are placed behind the UAG. The UAG checks the endpoint safety, and grants the user a logon screen. When the user is authenticated, it should be able to start his/her apps without any warning. Users are afraid to click on yes or no or trust always. They do not understand what is happening. It's already a huge dissapointment that SSO does not work with UAG and remote desktop, and the user has to authenticate twice. Now I also have to secure all servers behind the UAG with wildcard certificates.

    EDIT: maybe MS should get in contact with their friends at Citrix. There Secure gateway does a similar thing, but I only have to place a certificate from a trusted CA on the Secure gateway server. I can use my own internal CA to do the rest. The user will not be confronted with a message that it does not accept the internal CA certifcates placed on the terminal servers, because he/she does not have the root certificate installed. The Citrix secure gateway (acces gateway it's called nowadays) handles that part.


    MSCE

    Thursday, November 3, 2011 6:30 AM
  • Hi Ruud,

    "Internally you connect to the terminal servers fqdn. This fqdn matches the Common name on the certificate. That's why you do not get the warning. If you access from the internet you connect to the UAG portals fqdn, which has a certificate with a common name that matches the UAG internet fqdn."

    When connecting from outside, the browser connects to the UAG with the UAG portal's fqdn, etc. But after the user access the TS icon on the portal, the mstsc client is connecting to the backend TS server's fqdn (as definied in the UAG configuration). So it is not the "When the user is authenticated, it should be able to start his/her apps without any warning" because the check now is done by the mstsc client against the backend ts server, so if the certificate is not trusted, it will fail. You can see that if you install the backend certificate on the client as trusted, you should not get this warning.

    There is nothing wrong with this design, because the connection eventually is between the client and the backend server. The UAG just "open the gate" to allow the connection and it verify the client is authenticated correctly and protected, but when the client connet, it needs to verify the server and this is where you get the warning. The client trust the gateway but it does not mean it trust the backend application.

    It is also different protocols in this game - the client connect to the UAG using HTTPS but to the TS Server using RDP. The fact the HTTPS connection was validated does not mean the RDP protocol also secured. 

    Ophir.

    • Marked as answer by Ruud Boersma Thursday, November 3, 2011 8:08 AM
    Thursday, November 3, 2011 7:13 AM
  • One more thing, then i'll stop;) I already know now that I'll have to use a public wildcard cert, on all my TS.

    "But after the user access the TS icon on the portal, the mstsc client is connecting to the backend TS server's fqdn"

    Actually, like the screenshot says, it connects first to the gateway and then to the backend server. The GW, also has the same cert. in place as the UAG (name.domain.com). Why can't the gateway than validate the connection to the backend server, instead of the client, by placing the internal ca's root certificate on the UAG. Like Citrix access gateway does. It saves a lot of trouble. Offcourse the products are different, they do the same thing. Look at it as a feature request.


    MSCE
    Thursday, November 3, 2011 8:17 AM