0

Connectivity via RDP to our Microsoft Windows Server 2003 web and database servers unpredictably drops at varying points after we change the server dates. It usually occurs when we leave the server dates changed and remain logged in via RDP overnight. We can only restore RDP connectivity with a server reboot or a reset of the server dates to the current date.

We use these servers for web application user acceptance purposes; moving the server dates into the future simulates the passage of time in the web application. Staff then perform user acceptance tests of web application functionality.

Thanks for any insight into why this may be occurring. How would I even begin to debug such a problem? I am working with our hosting provider and hope to have additional details soon.

1
  • You could also increase log level of Cisco VPN client/server and post log file here for further review.
    – blank3
    Oct 27, 2009 at 9:20

2 Answers 2

1

Some protocols are sensitive about the time difference between communicating parties.

I remember having problems obtaining kerberos ticket with Samba from DC. When there was more than 5 minute difference between the two computers, the ticket was not issued.

I'd say it has to do with timestamping packets (maybe replay protection), so you'll probably have to keep their server times synced.

2
  • Thanks blank3; I appreciate your speedy response. Hopefully our service provider will be able to give additional insights into this issue. Also, the thought crossed my mind: would a protocol sensitive to time differences as you imply above work across time zones? For example, if I connect to a hypothetical server in India, the date/time of the remote system would be different.
    – iokevins
    Oct 27, 2009 at 4:13
  • Time sensitive protocols always use UTC so do not have time-zone issues.
    – LapTop006
    Oct 27, 2009 at 8:41
0

We identified the root cause and the solution.

First, the issue appears to be with RDP access to the server, not VPN; I have updated the question appropriately.

Second, the issue appears to be a failure to renew domain credentials after changing the server date.

The solution is to create a local user account on the server for use when changing the server date. In this way, re-authorization of expired domain credentials is not prevented by the difference in server dates.

So far, so good! We tested this on two servers today. On one, we created the local user account. On the other, our third-party software vendor used the domain account. They subsequently lost RDP access through the domain account but continued to have RDP access through the local user account.

Thanks to everyone for their assistance with this issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .