Paul Schmehl wrote: 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.

_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to