RDP from LAN but not from external addresses

[Guest Roger Vicker]

We had set up a W2K8 server (the only server in the organization) with User

CALs and everything was working fine inside and outside.

 

Just as we were rolling it out to the remote and roaming users it stopped

working.

 

Users on the local, to the server, network can still fully use RDP.

 

Outside users get to the server's full screen logon but no matter what

user/password they use they get a "The user name or password is invalid."

error. Same user/password works via the local network.

 

The event log was showing a 1004 id but a hot fix stopped that as MS

indicated it was a false event that led to useless investigation.

 

This started right in the middle of the day. A user was connected,

disconnected and rebooted to install a .NET update and from then on none of

the RDP users could get logged on unless they were on the local network.

 

The firewall isn't blocking the port as they are getting to the server's

logon screen.

 

What has changed?

 

How do we get the outside users to get fully logged in again?

 

Thanks.

[Guest Jeff Pitsch]

Re: RDP from LAN but not from external addresses

 

An end user installed a .net update? That's not good.

 

Does the firewall show any traffic going to the server? Can you telnet,

ping, etc to the server (opening up proper communication of course). If

you remove the .net update, does it start to work?

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

Roger Vicker wrote:

> We had set up a W2K8 server (the only server in the organization) with User

> CALs and everything was working fine inside and outside.

>

> Just as we were rolling it out to the remote and roaming users it stopped

> working.

>

> Users on the local, to the server, network can still fully use RDP.

>

> Outside users get to the server's full screen logon but no matter what

> user/password they use they get a "The user name or password is invalid."

> error. Same user/password works via the local network.

>

> The event log was showing a 1004 id but a hot fix stopped that as MS

> indicated it was a false event that led to useless investigation.

>

> This started right in the middle of the day. A user was connected,

> disconnected and rebooted to install a .NET update and from then on none of

> the RDP users could get logged on unless they were on the local network.

>

> The firewall isn't blocking the port as they are getting to the server's

> logon screen.

>

> What has changed?

>

> How do we get the outside users to get fully logged in again?

>

> Thanks.

[Guest Roger Vicker]

Re: RDP from LAN but not from external addresses

 

 

 

"Jeff Pitsch" wrote:

> An end user installed a .net update? That's not good.

>

> Does the firewall show any traffic going to the server? Can you telnet,

> ping, etc to the server (opening up proper communication of course). If

> you remove the .net update, does it start to work?

>

> Jeff Pitsch

> Microsoft MVP - Terminal Services

>

 

The .NET update is needed for the new printer driver support of Server 2008.

I actually included it on the CD for them to install in case MS Update hadn't

already.

 

Please re-read OP. Basic communications is working as they are getting to

the server to get its logon display. You know, the one with the blue

background, icons for last user, Other User, Smart Card and says Windows 2008

at the bottom, looks entirely different from Windows 2003... Also, it is

affecting all external users, not just the last one to try.

[Guest Jeff Pitsch]

Re: RDP from LAN but not from external addresses

 

Woops, wrong part to the wrong post. Sorry about that.

 

The NAT is still valid? It didn't get changed? Are there any errors in

the event logs when they try to login? Have you at least tried to

remove the update to see if it fixes the situation? Are they coming in

through TSWeb/TSGateway (i would assume yes for securities sake because

no one likes to have their internal network exposed to everybody but you

know what they say about assuming)?

 

It is never, ever a good idea to have users install an update. If the

server is ever put into install mode, it can completely corrupt the

shadow key if not worse. The administrator should always make sure the

proper updates are in place before the system is available to the users.

 

 

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

Roger Vicker wrote:

>

> "Jeff Pitsch" wrote:

>

>> An end user installed a .net update? That's not good.

>>

>> Does the firewall show any traffic going to the server? Can you telnet,

>> ping, etc to the server (opening up proper communication of course). If

>> you remove the .net update, does it start to work?

>>

>> Jeff Pitsch

>> Microsoft MVP - Terminal Services

>>

>

> The .NET update is needed for the new printer driver support of Server 2008.

> I actually included it on the CD for them to install in case MS Update hadn't

> already.

>

> Please re-read OP. Basic communications is working as they are getting to

> the server to get its logon display. You know, the one with the blue

> background, icons for last user, Other User, Smart Card and says Windows 2008

> at the bottom, looks entirely different from Windows 2003... Also, it is

> affecting all external users, not just the last one to try.

[Guest Roger Vicker]

Re: RDP from LAN but not from external addresses

 

 

 

"Jeff Pitsch" wrote:

> Woops, wrong part to the wrong post. Sorry about that.

>

> The NAT is still valid? It didn't get changed? Are there any errors in

> the event logs when they try to login? Have you at least tried to

> remove the update to see if it fixes the situation? Are they coming in

> through TSWeb/TSGateway (i would assume yes for securities sake because

> no one likes to have their internal network exposed to everybody but you

> know what they say about assuming)?

>

> It is never, ever a good idea to have users install an update. If the

> server is ever put into install mode, it can completely corrupt the

> shadow key if not worse. The administrator should always make sure the

> proper updates are in place before the system is available to the users.

>

>

>

> Jeff Pitsch

> Microsoft MVP - Terminal Services

>

1) NAT is working as THEY ARE GETTING THE LOGON SCREEN FROM THE SERVER.

 

2) There were ID 1004 errors in the logs but a MS Hotfix stopped them as it

stated they were coming from a false condition. Nothing about TS since then.

 

3) I haven't removed the update as the problem is affecting other machines

that were working and had the update long before things stopped working.

 

4) They are coming in via the RDP port being mapped in the firewall to the

server. Using the RDP client 6.1. This is not TSWeb at this stage and there

is no TSGateway. I said that there is ONLY ONE SERVER total.

 

5) The update was applied to the USER'S PC. Users have no special rights on

the server. The update was just why the user disconnected and then minutes

later tried to reconnect. I mentioned it to show that there wasn't an

overnight, reboot, server change between it working and not working.

 

The .NET Framework update did not cause the problem because:

 

1) It was applied to only one CLIENT PC. The others already had it applied

via MS Update some time ago.

 

2) The problem is blocking ALL CLIENTS OUTSIDE THE FIREWALL.

 

3) Clients inside the firewall can connect and work using the exact same

user/password as those trying from outside the firewall.

 

4) Probable indication that it is not the problem is that I can logon using

the same client PC to a server running 2003 SBS on an entirely different

network but not this server.

 

The firewall is not causing this unless TS suddenly requires something other

than the RDP port being open/mapped. REPEAT: The client is connecting to the

server, the server is just rejecting the user/password when the connection is

coming from outside the firewall but accepting it when coming from inside the

firewall. We are not talking about the user name/credentials that can be

stored with the .RDP file. The .RDP file has the user name left blank and

there is no check mark for "Allow me to save credentials"

 

Rebooting the server didn't clear the problem but 72+ hours seems to have.

However, the client disk drives don't show in Explorer despite the .RDP being

checked and the GPO doesn't say to disallow it. Also, printing to the client

printers never produces anything and there are no errors. They are via the

new TS Easy Print drivers.

[Guest Vera Noest [MVP]]

Re: RDP from LAN but not from external addresses

 

=?Utf-8?B?Um9nZXIgVmlja2Vy?=

<RogerVicker@discussions.microsoft.com> wrote on 21 sep 2008 in

microsoft.public.windows.terminal_services:

> 1) NAT is working as THEY ARE GETTING THE LOGON SCREEN FROM THE

> SERVER.

>

> 2) There were ID 1004 errors in the logs but a MS Hotfix stopped

> them as it stated they were coming from a false condition.

> Nothing about TS since then.

>

> 3) I haven't removed the update as the problem is affecting

> other machines that were working and had the update long before

> things stopped working.

>

> 4) They are coming in via the RDP port being mapped in the

> firewall to the server. Using the RDP client 6.1. This is not

> TSWeb at this stage and there is no TSGateway. I said that there

> is ONLY ONE SERVER total.

>

> 5) The update was applied to the USER'S PC. Users have no

> special rights on the server. The update was just why the user

> disconnected and then minutes later tried to reconnect. I

> mentioned it to show that there wasn't an overnight, reboot,

> server change between it working and not working.

>

> The .NET Framework update did not cause the problem because:

>

> 1) It was applied to only one CLIENT PC. The others already had

> it applied via MS Update some time ago.

>

> 2) The problem is blocking ALL CLIENTS OUTSIDE THE FIREWALL.

>

> 3) Clients inside the firewall can connect and work using the

> exact same user/password as those trying from outside the

> firewall.

>

> 4) Probable indication that it is not the problem is that I can

> logon using the same client PC to a server running 2003 SBS on

> an entirely different network but not this server.

>

> The firewall is not causing this unless TS suddenly requires

> something other than the RDP port being open/mapped. REPEAT: The

> client is connecting to the server, the server is just rejecting

> the user/password when the connection is coming from outside the

> firewall but accepting it when coming from inside the firewall.

> We are not talking about the user name/credentials that can be

> stored with the .RDP file. The .RDP file has the user name left

> blank and there is no check mark for "Allow me to save

> credentials"

>

> Rebooting the server didn't clear the problem but 72+ hours

> seems to have. However, the client disk drives don't show in

> Explorer despite the .RDP being checked and the GPO doesn't say

> to disallow it. Also, printing to the client printers never

> produces anything and there are no errors. They are via the new

> TS Easy Print drivers.

 

Roger, when you say that there is only a single server, do you mean

that the TS is a standalone server in a workgroup, and the users

have local user accounts on the TS, or is there a DC and the TS is

a member of AD?

Is Single Sign-On enabled on the server?

 

_________________________________________________________

Vera Noest

MCSE, CCEA, Microsoft MVP - Terminal Server

TS troubleshooting: http://ts.veranoest.net

___ please respond in newsgroup, NOT by private email ___

[Guest Jeff Pitsch]

Re: RDP from LAN but not from external addresses

 

My point on the NAT was that it could have been changed and it was

pointed at a different server. Also, you can run all 3 roles on the

same server so yes, TSWeb/TSGateway could be installed and you still

only have one server.

 

And this information you provided in this post is much more detailed

than previously and explains the situation much better. Thank you.

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

Roger Vicker wrote:

>

> "Jeff Pitsch" wrote:

>

>> Woops, wrong part to the wrong post. Sorry about that.

>>

>> The NAT is still valid? It didn't get changed? Are there any errors in

>> the event logs when they try to login? Have you at least tried to

>> remove the update to see if it fixes the situation? Are they coming in

>> through TSWeb/TSGateway (i would assume yes for securities sake because

>> no one likes to have their internal network exposed to everybody but you

>> know what they say about assuming)?

>>

>> It is never, ever a good idea to have users install an update. If the

>> server is ever put into install mode, it can completely corrupt the

>> shadow key if not worse. The administrator should always make sure the

>> proper updates are in place before the system is available to the users.

>>

>>

>>

>> Jeff Pitsch

>> Microsoft MVP - Terminal Services

>>

> 1) NAT is working as THEY ARE GETTING THE LOGON SCREEN FROM THE SERVER.

>

> 2) There were ID 1004 errors in the logs but a MS Hotfix stopped them as it

> stated they were coming from a false condition. Nothing about TS since then.

>

> 3) I haven't removed the update as the problem is affecting other machines

> that were working and had the update long before things stopped working.

>

> 4) They are coming in via the RDP port being mapped in the firewall to the

> server. Using the RDP client 6.1. This is not TSWeb at this stage and there

> is no TSGateway. I said that there is ONLY ONE SERVER total.

>

> 5) The update was applied to the USER'S PC. Users have no special rights on

> the server. The update was just why the user disconnected and then minutes

> later tried to reconnect. I mentioned it to show that there wasn't an

> overnight, reboot, server change between it working and not working.

>

> The .NET Framework update did not cause the problem because:

>

> 1) It was applied to only one CLIENT PC. The others already had it applied

> via MS Update some time ago.

>

> 2) The problem is blocking ALL CLIENTS OUTSIDE THE FIREWALL.

>

> 3) Clients inside the firewall can connect and work using the exact same

> user/password as those trying from outside the firewall.

>

> 4) Probable indication that it is not the problem is that I can logon using

> the same client PC to a server running 2003 SBS on an entirely different

> network but not this server.

>

> The firewall is not causing this unless TS suddenly requires something other

> than the RDP port being open/mapped. REPEAT: The client is connecting to the

> server, the server is just rejecting the user/password when the connection is

> coming from outside the firewall but accepting it when coming from inside the

> firewall. We are not talking about the user name/credentials that can be

> stored with the .RDP file. The .RDP file has the user name left blank and

> there is no check mark for "Allow me to save credentials"

>

> Rebooting the server didn't clear the problem but 72+ hours seems to have.

> However, the client disk drives don't show in Explorer despite the .RDP being

> checked and the GPO doesn't say to disallow it. Also, printing to the client

> printers never produces anything and there are no errors. They are via the

> new TS Easy Print drivers.

>

[Guest Roger Vicker]

Re: RDP from LAN but not from external addresses

 

 

 

"Vera Noest [MVP]" wrote:

 

>

> Roger, when you say that there is only a single server, do you mean

> that the TS is a standalone server in a workgroup, and the users

> have local user accounts on the TS, or is there a DC and the TS is

> a member of AD?

> Is Single Sign-On enabled on the server?

>

> _________________________________________________________

> Vera Noest

> MCSE, CCEA, Microsoft MVP - Terminal Server

> TS troubleshooting: http://ts.veranoest.net

> ___ please respond in newsgroup, NOT by private email ___

>

 

Single server as it it is the only system running server OS and is

everything, DC, TS, App server, file server...

 

Single Sign On is not in use.

[Guest Vera Noest [MVP]]

Re: RDP from LAN but not from external addresses

 

=?Utf-8?B?Um9nZXIgVmlja2Vy?=

<RogerVicker@discussions.microsoft.com> wrote on 21 sep 2008 in

microsoft.public.windows.terminal_services:

> "Vera Noest [MVP]" wrote:

>>

>> Roger, when you say that there is only a single server, do you

>> mean that the TS is a standalone server in a workgroup, and the

>> users have local user accounts on the TS, or is there a DC and

>> the TS is a member of AD?

>> Is Single Sign-On enabled on the server?

>

> Single server as it it is the only system running server OS and

> is everything, DC, TS, App server, file server...

>

> Single Sign On is not in use.

 

OK, running TS on a DC is *not* recommended, for obvious security

reasons, but it shouldn't cause the problems you mention.

However, you should keep in mind that users could have modified all

kinds of things, and double-check all settings which you believe to

be in effect to see if they are still as you configured them.

 

You wrote in an earlier post:

>> Rebooting the server didn't clear the problem but 72+ hours

>> seems to have.

 

OK, so outside users *can* logon now?

Sounds really weird. I would investigate these areas:

* check the logs on the firewall to see if some traffic was

rejected

* maybe there was a problem with Kerberos authentication?

>> However, the client disk drives don't show in

>> Explorer despite the .RDP being checked and the GPO doesn't say

>> to disallow it. Also, printing to the client printers never

>> produces anything and there are no errors.

 

These problems could indicate that GPOs are not applied as they

should. I'd enable verbose logging of the user environment, and

compare remote and local user logon processes.

 

221833 - How to enable user environment debug logging in retail

builds of Windows

http://support.microsoft.com/?kbid=221833

 

_________________________________________________________

Vera Noest

MCSE, CCEA, Microsoft MVP - Terminal Server

TS troubleshooting: http://ts.veranoest.net

___ please respond in newsgroup, NOT by private email ___