Wireless Access

Reply
Highlighted
Regular Contributor II

System clock of Managed devices

Hello,

 

We have office located all over the country and each of the offices are in different time zones. We have 2 x Mobility Master at our Head Quarters and 2 x hardware Local Controllers at each office.  Everything is communicating just fine with the Mobility Masters and the controllers.

 

We also have setup Active Directory servers at each site and then Network Policy Servers (NPS) at each site for the local controllers to use for company authentication.  When I was first beta testing the local controllers at a remote site, I temporarily used the H.Q. NPS servers because the other site's NPS servers were not setup yet.  The Active Directroy Authentication for the remote Site's Local Controlllers only worked when I changed the Time Zone for the local controllers to match the AD server Time Zone that they were authenticating from(H.Q. Time Zone).  Because the NPS servers located in H.Q. werte using the H.Q Active Directory Servers.

 

Eventually, when we setup new NPS servers at the remote site, I then configured the local controllers to use those local NPS servers and changed the time zone to match.  My question is, why must the local controllers match the Time Zone of the Active Directory Servers being used to authenticate?

 

Thanks,


Accepted Solutions
MVP Guru

Re: System clock of Managed devices

I believe it is due to the maximum tolerance for time of an authentication source, I believe for AD it is within 5 minutes. There is usually a time stamp as part of its protocol definition. For time stamps to work properly, the clocks of the client/device and the domain controller need to be in sync as much as possible. If the difference between a client/device source clock and the domain controller clock is less than the maximum time difference AD will reject it.


ACMP, ACSA, ACDX #985
If my post addresses your query, give kudos:)

View solution in original post


All Replies
MVP Guru

Re: System clock of Managed devices

I believe it is due to the maximum tolerance for time of an authentication source, I believe for AD it is within 5 minutes. There is usually a time stamp as part of its protocol definition. For time stamps to work properly, the clocks of the client/device and the domain controller need to be in sync as much as possible. If the difference between a client/device source clock and the domain controller clock is less than the maximum time difference AD will reject it.


ACMP, ACSA, ACDX #985
If my post addresses your query, give kudos:)

View solution in original post

Highlighted
Regular Contributor II

Re: System clock of Managed devices

That sounds like a very good explanation.

 

I have a seprate but related quesiton, if I may ask. 

 

If we wanted to have some NPS servers from another location (using  their own AD servers configured with a different time zone)  for a tertiary NPS server.  How can we do that?

 

The only thing I can think of is:

1.  Setup the other NPS Servers on the controllers.

2.  Setup those remote NPS server with the Aruba Controllers as clients.

3.  Then if the primary NPS servers are not available I will need to manually change the configurations on the controllers and their assoicated Time Zone.

4.  Then when the primary NPS servers are ready to work again... then I will need configure everything back to how it was before.

 

That is not an automatic way of doing it but that is the only way I can think of to get back in business if there is a problem.  Can anyone suggested a better process for a tertiary NPS from another time zone?

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: