So i recently went into a small client to setup a single server RDWeb/RDGateway/RD Session host server… “simple enough” i thought… how wrong i was.
When having a dedicated RDWeb/RD Gateway and a farm behind it – it all fits together nicely… on a single box, i seemed to need to use SAN certs…. which for testing purposes i used the internal enterprise CA to issue and published an online responder for the revocation…. all worked fine in win7…. and i pulled my hair out for days trying to work out why the XP SSO wasnt working….
XP doesnt support online responders…. and if it cant retrieve the revocation infromation, a really fucking unhelpful error message of “the connection has been terminated because an unexpected server authentication certificate….” – FFS… there goes two wasted days of my life … i am absolutely fucking livid….
RD Gateway is great – but the logging is shithouse… it could really do with an equivalent of www.testexchangeconnectivity.com….. would be very handy (and an all in one RDC7/CredSSP/Reg entries package for XP SP3 would be nice too!)
I am currently going through the same nightmare, however a much more complex setup. I originally set up around 30 session host servers, two brokers, etc and using our internal CA. Everything (including SSO) was working great! Then I was asked to get this working from outside our corporate network.
I read up on the RD Gateway (not much info posted by Microsoft), purchased a UAC certificate (supports SAN’s) from Comodo and installed it on ISA and the gateway. From the outside, the no cert errors when connecting to the gateway, but upon launch of an app (signed with an internal certificate), we were prompted with a CRL error. The client was trying to validate the internal certificate! What good is a proxy/gateway server if the client is trying to validate internal resources! I called Microsoft and was told you have to use a public certificate to sign the applications. After telling them it was a poor design, I installed the cert on all of the internal servers and tested again. Guess what? That broke access from the inside! Now the internal clients were getting a CRL error because it uses the service account (which doesn’t know anything about a proxy server) to check the public CRL. After days on the phone with Microsoft, this still isn’t working. Does ANYONE have this working both internally and externally with a proxy server? (We already tried adding the CRL sites through the proxy server without authenticating, but the client never even tries to hit the proxy and we don’t want to open the firewall to a bunch of CRL web sites,)
it does work – its just poorly documented (Microsoft seem to have a policy of leaving doco as vague as possible – and whatever you dont point out corrections to CSS – they dont react well to that)
Basically i’ve learnt that
1) Trying to use internal certs is not a good way to go…. dont bother, just use external certs
2) When it works, it works well, but when it doesn’t…. the logging and troubleshooting sucks in a big way
3) Using consistent internal and external names (which i always try to do anyway) definately makes life easier, both from an admin point of view and user-experience point of view
Anyhoo – once you have external certs being used for both levels – you should be fine. Im not quite sure where your proxy is coming into this. Your certs should have the RDGateway name, farm name and server names for the subjects. The proxy (i assume ISA) – is just used to reverse publish – nothing else.
I am looking at deploying a similar setup, 2 to 4 RDWeb/RDGateway servers, 2 RDCB Active/Passive, 4 to 8 RDSH servers and have been searching around on info about certificates, I plan on integrating the deployment into our http://www.mycompany.com and use our EV cert for both RDWeb and RDGateway, would sign the RemoteApp packages with the EV cert but I have been hung up on if I need to use UCC certs for the public webpage and include all the internal RDSH servers or if I can use public certs with the fqdn for each machine. I don’t want to spend any money until I know what I need and I don’t need internal access the farm will only be accessed by external clients that are not part of the same domain. I’ve also been wondering about hardware specs, I’m using Hyper-V and am planning 1 vCPU w/2GB RAM for the web servers, 2 vCPU w/4GB RAM for RDCB and either 2 vCPU w/4GB or 4 vCPU w/8GB RAM for RDSH I either spread the load across a few hosts with higher specs or over even more servers with lower specs. I’m hoping to fit around 150 to 200 users on the deployment.
Just noticed this on the side bar while reading your SCCM drivers article… glad to know I’m not the only one who finds RDWeb poorly designed (putting it nicely!)
The XP SP3 updates package would be so simple for MS to provide as part of a pre-req connectivity test when you login… then again so would an option to transparently set the default logon domain but they missed that bit too (already done the login page code tweak but it’s far from ideal).
Gave up with RDWeb in the end and used another remote access package that manages to do smooth SSO from login screen to a Remote Desktop session… if an open-source project can do it why can’t Microsoft?
as per so many things – its just so much harder than it needs to be!
Gerrard – what was the open source package you used to smooth SSO?
On another note – publishing the gateways’ NLB and the rdweb front end over ISA 2006 EE is killing us. We’re getting 3-10 minutes time to for the Outlook remote app to open, so users are abandoning the remote access method in droves.
Thanks,
Victor
3-10 minutes is nuts – there must be something busted there.
RDP via RDGateway/Web is slower than what it should be… but were talking 15-30 seconds…. not 3-10 mins!
CRL checking being busted can signifcantly increase the logon times…. perhaps that would be a good thing to check first ?
I’d suggest its the NAP policies that are slowing down connection times, if your clients are not on the same domain this won’t work anyway so remove the feature and things should speed up.
Finally make sure Apps are signed with the same ssl cert as the rdweb site so you get SSO. Unfortunately SSO will only work with Win7 onwards.
Bit of an old post now mate…. since then, a couple of things have happened
1) I’ve done many more installs – and while the feature limitations are still annoying, ive learnt to accept its not an enterprise solution.
2) Win 7 or greater is now the standard desktop OS, so the CredSSP issue goes away
As a side note, there was no NAP – so im not sure where that suggestion comes from (although yes, that could slow things down – but not when its not in use) and SSO does indeed work with XP, you just need to jump through hoops to get it working (credSSP provider, RDP 7 client and registry settings) – and have some type of management over the machines in question (which makes it useless for non-domain joined machines)