[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 86
  • Last Modified:

Active Directory Time

Hi,

I have a quick question, what are the consequences of having a member server on a different time zone to its Active Directory Domain?  I have an application that needs to connect to a server in a different time zone (the server in the different time zone and the member server, have to have the same time) and the users in the AD domain connect to this member server for one of our applications.  What problems could this bring up?

Cheers
0
minniejp
Asked:
minniejp
  • 7
  • 4
  • 2
  • +1
1 Solution
 
Seth SimmonsSr. Systems AdministratorCommented:
no problems as long as the time is correct
many things actually use GMT though it's displayed in the time zone it is currently in
as long as the server time is correct for that time zone, it will be fine
if a server in boston shows 1pm EST and a server in san francisco shows 10am PST then that is fine
0
 
QlemoC++ DeveloperCommented:
The servers will not have issues, any sync is based on UTC. Applications manage time zone handling themselves, so you can't tell in general.
0
 
minniejpAuthor Commented:
Thanks all...Is there a scenario where time differences are a problem?
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
Cliff GaliherCommented:
Yes. I am concerned by this statement, as it is rather ambiguous:

 "the server in the different time zone and the member server, have to have the same time"

If you are saying that a server set to the Pacific timezone and another server set to the Eastern timezone (for example) most both report their local time as 10am instead of accommodating the timezone difference then that *will* be a problem. In order to minimize man-in-the-middle and various replay attacks, the authentication schemes supported by windows (Kerberos, and even NTLM) do not allow a skew of more than a few minutes. And having two servers report the same "local" time but have different timezones is, by definition, a skew of an hour or more, depending on the time difference between the selected timezones.  Most functionality that relies on Active Directory (logins, group policies, etc) will simply not work.

-Cliff
0
 
minniejpAuthor Commented:
Thanks Cliff.  I need to change a Server that is a member server within a AD Domain that is in the Pacific Timezone to GMT, allowing it to run an application that is on a Server in the UK (GMT) (both servers need to have the same time).  Users in the AD Domain in the Pacific Timezone then log onto this member server but is this going to work if this server is a number of hours ahead in GMT and the users logging into it are in Pacific?  

In summary, I need this member server to have the same time as the server based in the UK (for this application to work) but i'm not 100% sure of the consequences.  

Cheers
0
 
Cliff GaliherCommented:
Unfortunately your statement about the servers needing to have "the same time" is still ambiguous. If their times would be the same when converted to UTC then you'll have no issues. If they each have a local time that appears the same (so both would claim to be 10AM if viewed side by side) but are in different time zones then that is a significant problem with no good workaround. The phrase "same time" could be interpreted either way as illustrated by the examples above. One is fine. The other is very problematic and the only viable resolution would be to get the application changed to respect timezones.
0
 
QlemoC++ DeveloperCommented:
That is summarized well. The main issue probably is the application not being able to work with timezone.
0
 
minniejpAuthor Commented:
Thanks for your reply.  As long as the time on both Servers (UK and the one server in US) have the same time (10am) then this is enough.  I don't believe they necessarily need to be on the same time zone.  I was going to change the registry on the US server and tell it to get its time from a UK time Source rather than its own US Domain Controller.
0
 
minniejpAuthor Commented:
My worry was around Active Directory and how it would react to a server on the domain having a different time and what problems it may cause in users logging into the Server (they obviously will have a US time and the Server (based in US) will have a UK time).

Sorry for the confusing statements, hopefully I have explained this better than above.
0
 
Cliff GaliherCommented:
"As long as the time on both Servers (UK and the one server in US) have the same time (10am) then this is enough.  I don't believe they necessarily need to be on the same time zone."  

That is exactly the scenario you *DON'T* want. Such a configuration would break authentication with the one server where the time doesn't match the appropriate timezone.
0
 
minniejpAuthor Commented:
Great! I wanted to be sure I didn't break the Authentication! So, same time on server, with the registry set to a time source in UK and keep in time zone to US!

Cheers Cliff
0
 
minniejpAuthor Commented:
Sorry Cliff, I'm just reading your reply again and I think I read it wrong.  Please see below:

Application Server in UK - Time Zone GMT - Time 10am

Application Server in USA - Time Zone UTC  - Time 10am

Domain Controller in USA - Time Zone UTC - Time  5am

Is this scenario OK or should it be:


Application Server in UK - Time Zone GMT - Time 10am

Application Server in USA - Time Zone GMT  - Time 10am

Domain Controller in USA - Time Zone UTC - Time  5am

Thanks for the clarification
Cheers
0
 
Cliff GaliherCommented:
Second scenario. The first will break.
0
 
minniejpAuthor Commented:
Thanks Cliff
0

Featured Post

Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

  • 7
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now