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.
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.
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.
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,
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"