connecting to a secured Windows 2003 terminal server

[Steve Bertrand]

Paul Schmehl wrote:

> 
> Umm..no.  In Windows-land, Terminal Services == rdp (port 3389 TCP) but 
> a terminal *server* is used specifically to allow mutliple (as in more 
> than the default limit of two) concurrent sessions and requires the 
> purchase of additional licenses.  Now, *maybe* the OP really meant 
> terminal *services* but he wrote "secured Windows 2003 terminal 
> *server*", and that is a different animal altogether.

Ok, fair enough. I was hasty in reading the OP's original post.

>> Failing that, see if there is a 'feature' to drop back to non-SSL mode
>> for RDP for the time being, to at least get the FBSD boxen to 'see' the
>> service. Troubleshooting can commence from there.
>>
> If you like sending your credentials across the internet in clear text, 
> be my guest.  I wouldn't suggest to the OP that he ask his enterprise to 
> expose themselves to that level of risk.

I'll rephrase... if there is the possibility to adding a temporary, 
non-privileged user to the enterprise network that you are currently 
testing that only has specific rights to authenticate via Terminal 
Server and no rights otherwise whatsoever, then I would try that.

Commencing the test, I would immediately remove the user account.

Otherwise, I would configure a separate Windows 2k3 box, exactly the 
same as the one that was upgraded, and test the scenario in a closed, 
less-sensitive environment.

The logs should provide guidance to the cause of the problem. I'm more 
familiar with FreeBSD, so I would start there. However, perhaps the 
Windows logging system has something to offer.

I would still try nmap and telnet, and the other tests.

Especially given the fact that OP never specified that he would be 
sending credentials over a public network at all.

Besides... in the original post, it was clarified that the old server 
did NOT have any encryption whatsoever.

Steve