You are on page 1of 4

ACS 5.

x: Cisco ACS Synchronization with NTP


Server Configuration Example
Document ID: 113579

Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Configure
NTP Configuration on Cisco ACS
Verify
Troubleshoot
Problem: Clock drifts too much and NTP fails when ACS is installed on a VMWare machine
Solution
NTP Synchronization lost after the interface IP address of ACS is changed
Solution
Related Information
Introduction
Network Time Protocol (NTP) is a protocol used in order to synchronize the clocks of different network
entities. It uses UDP/123. The main objective to use this protocol is to avoid the effects of variable latency
over the data networks.

This document provides a sample configuration for the Cisco ACS to synchronize its clock with NTP server.
ACS 5.x is allowed to configure up to two NTP servers.

Prerequisites
Requirements
There are no specific requirements for this document.

Components Used
The information in this document is based on these software and hardware versions:

Cisco Secure ACS Version 5.x

The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.

Conventions
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Configure
In this section, you are presented with the information to configure the features described in this document.

Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the
commands used in this section.

NTP Configuration on Cisco ACS


In order to synchronize the time of Cisco ACS with an NTP server, complete these steps:

1. Manually configure the date and time with the clock set <month> <day> <hh:min:ss> <yyyy>
command.
2. Specify the time zone with the clock timezone <timezone> command.
3. Specify the NTP server with the NTP server <IP address of NTP server> command.

NTP follows a clientserver hierarchy. When an NTP client is configured with an NTP server, the
Reference Clock of the NTP server is passed to the client. It takes approximately 1020 minutes to get
the accurate time from the NTP server and depends on the delay occurs in order to reach the NTP
server.

Cisco ACS uses the NTP daemon in order to synchronize its clock with the NTP server. It does not
support the Simple NTP, SNTP. When the NTP daemon starts, ACS sends a packet to the NTP server
that contains its original time (Local). Then NTP server replies to the packet with the insertion of its
Reference Clock time. Once the NTP client receives this packet, it logs the packet with its own local
time in order to validate the traveling time taken by the packet. Several such packet exchanges occur
in order to calculate the exact round trip delay time and offset values and finally the local time of NTP
client is synchronized with the Reference Clock of the NTP server.

Verify
Use this section in order to confirm that your configuration works properly.

In order to verify the configuration details, refer to these command output snippets.

acs51/admin#show clock
Wed Jun 13 11:02:00 IST 2012
acs51/admin#

acs51/admin(config)#ntp server 192.168.26.55


The NTP server was modified.
If this action resulted in a clock modification, you must restart ACS.
acs51/admin(config)#

acs51/admin#show ntp
Primary NTP : 192.168.26.55

synchronised to NTP server (192.168.26.55) at stratum 2


time correct to within 27 ms
polling server every 64 s

remote refid st t when poll reach delay offset jitter


==============================================================================
127.127.1.0 LOCAL(0) 10 l 29 64 17 0.000 0.000 0.001
*192.168.26.55 .LOCL. 1 u 33 64 17 0.285 9.900 2.733
Warning: Output results may conflict during periods of changing synchronization.

Note: Stratum is a measure that specifies how close is the NTP server to the Primary Reference Clock. Each
NTP client that is synchronized with a stratum n server is termed as at stratum n+1 level.

Refer to these application log messages from ACS in order to verify the NTP Synchronization details.

acs51/admin# show logging application | in ntp


Jun 13 13:51:59 acs51 ntpd[20259]: ntpd 4.2.0a@1.1190r Mon Jul 28 11:03:50 EDT 2008 (1)
Jun 13 13:51:59 acs51 ntpd[20259]: precision = 1.000 usec
Jun 13 13:51:59 acs51 ntpd[20259]: Listening on interface wildcard, 0.0.0.0#123
Jun 13 13:51:59 acs51 ntpd[20259]: Listening on interface wildcard, ::#123
Jun 13 13:51:59 acs51 ntpd[20259]: Listening on interface lo, 127.0.0.1#123
Jun 13 13:51:59 acs51 ntpd[20259]: Listening on interface eth0, 192.168.26.51#123
Jun 13 13:51:59 acs51 ntpd[20259]: kernel time sync status 0040
Jun 13 13:51:59 acs51 ntpd[20259]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Jun 13 13:51:59 acs51 ntpd: ntpd startup succeeded
Jun 13 13:55:15 acs51 ntpd[20259]: synchronized to 192.168.26.55, stratum 2

! Output suppressed

The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT
to view an analysis of show command output.

Troubleshoot
This section provides information you can use to troubleshoot your configuration.

Problem: Clock drifts too much and NTP fails when ACS is installed on a
VMWare machine
Cisco ACS is configured to use the NTP server as the clock source but it continually changes to the internal
time source. When this happens, it does notallow users to authenticate from Active Directory as Kerberos only
supports 300 seconds of time difference.

Solution
When the ESXi host has high CPU utilization, then it does not serve VMs as frequently as normal. This
affects the clocks inside VMs and actually cause clock drift from a Windows Domain Controller that exceeds
five minutes. It causes the Kerberos to fail. This would impact a Windows VM without NTP or host clock
sync as well. As the virtual clock presented to Cisco ACS is not stable enough for NTP to keep up with the
drift, it eventually reverts to using itself as a time source.

Note: The NTP daemon adjusts the clock in several exchanges and continues until the client obtain the
accurate time. However, when the delay between NTP Server and the NTP Client become too big, then the
NTP daemon gets terminated and you need to adjust the time manually and restart the NTP daemon.

This problem is set to be resolved when you integrate the VMWare tools support into Cisco ACS, which is
available with Cisco ACS release 5.4 that is yet to be released. Refer to Cisco bug ID CSCtg50048 (registered
customers only) for more information. As a temporary workaround, you could try these steps:

Stop ACS services with the ACS stop command .


Remove all NTP configuration and save the configuration with a write mem command.
Reboot Cisco ACS.
Make sure all services are running with the show application status acs command.
Set the clock to be as close to real time as possible, to the second before of the offset requirement on
NTP.
Make sure Timezone is correct one.
Readd NTP configuration and save it.
Perform the show ntp command in order to verify if the output is the same.

Note: If these steps do not resolve the issue, you are advised to contact Cisco TAC.

NTP Synchronization lost after the interface IP address of ACS is


changed
If you change the IP address of ACS NIC, this makes the NTP go out of sync.

Solution
This behavior is observed and logged in Cisco bug ID CSCtk76151 (registered customers only) . When the
ACS IP address is modified, it restarts the ACS application but not the NTP daemon. It is fixed in ACS
version 5.3.0.23. In order to resolve this issue in prior versions, complete these steps:

1. Issue the no ntp server command in order to stop the NTP process.
2. Reissue the ntp server command in order to restart the NTP process.

Related Information
CS ACS 5.X Product Support
User Guide for the Cisco Secure Access Control System 5.3
Technical Support & Documentation Cisco Systems

Contacts & Feedback | Help | Site Map


2011 2012 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.

Updated: Jun 15, 2012 Document ID: 113579