Roger Sohn

This is a common error found on domain controllers if NTP is not configured correctly.

Symptom:

When you try to synchronize your Microsoft Windows Server 2003-based computer to a Network Time Protocol (NTP) server that is not running Microsoft Windows, the synchronization may not succeed. When this problem occurs, the following events may be recorded in the System log:

Event Type: Error
Event Source: W32Time
Event Category: None
Event ID: 29
Date: Date
Time: Time
User: N/A
Computer: ComputerName

Description: The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time.

Cause:

This problem may occur when your computer sends synchronization requests by using symmetric active mode. By default, Windows Server 2003 domain controllers are configured as time servers and use symmetric active mode to send synchronization requests. Some NTP servers that do not run Windows respond only to requests that use client mode.

Resolution:

To resolve this problem, configure Windows Time to use client mode when it synchronizes with the time server. To do this, follow these steps:

1. Click Start, click Run, type cmd, and then press ENTER.

2. At the command prompt, type the following commands in the order that they are given. After you type each command, press ENTER.

o w32tm /config /manualpeerlist:NTP_server_IP_Address,0×8 /syncfromflags:MANUAL

o net stop w32time

o net start w32time

o w32tm /resync

Additional Info:

The mode that Windows Time uses to send requests is set by the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer

If the value of the Enabled entry in this subkey is 1, Windows Time uses symmetric active mode. Otherwise, Windows Time uses client mode.

The 0×8 setting that is referenced in the command in the “Resolution” section sets Windows Time to use client mode.

The valid settings for the mode used with the /manualpeerlist switch include the following:

· 0×01 - use special poll interval SpecialInterval

· 0×02 - UseAsFallbackOnly

· 0×04 - send request as SymmetricActive mode

· 0×08 - send request as Client mode

Microsoft KB Article: http://support.microsoft.com/kb/875424

If you are backing up an SQL server, it’s advisable to perform a consistency check as part of the backup. When this check fails, it can be hard to work out why, so you can run a check manually. These instructions are for SQL Server 2005.

• Open SQL Management Studio and connect to the SQL server.
• Browse to the database which is reporting consistency check errors
• Ensure the database is highlighted in the Object Explorer pane.
• Click the New Query button.
• In the pane which opens, enter DBCC CHECKDB
• Click Execute (or press F5)
• The check may take a little while to run. The results are displayed in the Messages window.
• If the check completed successfully, the messages should end with CHECKDB found 0 allocation errors and 0 consistency errors in database ‘TestDB’.

Steps to configure WPA on a Cisco Aironet 1100, 1200, 1230, 1240 Series Access Points

Please follow these steps on GUI:

• Open the GUI of the Access Point.
• Go to Security Encryption Manager.
• Select Cipher and choose TKIP from the list.
• Set encryption key 2 as transmit key. (Don’t put any key there)
• Click Apply.
• Select SSID Manager.
• Select SSID and scroll down to “Client Authenticated Key Management”
• Select Key Management to Mandatory and check WPA box.
• Write down the WPA-PSK key
• Scroll down and click Apply.

Commands to enable WPA through CLI:

AP(config)#interface dot11Radio 0

AP(config-if)#encryption mode ciphers tkip

AP(config-if)#ssid ssid_name

AP(config-if-ssid)#authentication open

AP(config-if-ssid)#authentication key-management wpa

AP(config-if-ssid)#wpa-psk ascii pre-shared_key

Please see the following document for further details:

http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_configuration_example09186a00801c40b6.shtml

Q: What are the major security concerns for companies using FTP and Telnet?

A: The main problem with FTP or Telnet is that they are fundamentally insecure protocols. FTP dates back from the 60’s when it was commissioned by DARPA and Telnet was created a bit earlier. That was a time when network security was not as much of a concern as it is today. Both protocols were designed with simplicity, versatility and flexibility in mind, but definitely not security. FTP is primarily used for transferring files between homogeneous or heterogeneous environments while Telnet is the de facto protocol for accessing text-based legacy applications or remotely managing servers and network equipment.

Both FTP and Telnet have many security issues, but the most critical are:

• Clear-text transmission: all communications are done in clear text, including usernames and passwords
• Weak client authentication: both FTP and Telnet authenticate users through usernames and passwords, which, time and time again, have proven to be unreliable authentication methods. There is no support for more advanced authentication methods such as public/private key, Kerberos or digital certificates
• No server authentication: this means that users have no way to be sure that the host they are communicating with really is the FTP server and not an attacker impersonating the server
• Absence of data integrity: problem here is that, assuming the same scenario as above, anyone could alter and corrupt the data being transmitted between the server and the client without being noticed
There are more problems related to FTP and Telnet such as the many exploits available on the Internet or the fact that they don’t play nice with firewalls. Ultimately, these technical problems become critical business challenges which amount to two things: cost of a security breach and lack of compliance with industry standards.

According to a 2007 Forrester study, security breaches cost anywhere between $90 to $305 per record breached. As an example, the breach of a simple text file containing 5,000 names, addresses and social security numbers or credit card numbers would end up costing between $450,000 and $1,525,000. This is the kind of money that businesses can not afford to pay these days, especially when you realize that adequately protecting yourself against simple breaches like FTP or Telnet is going to cost you between 1% and 5% of that amount.

At the end of the day, it’s not about the technicalities of security, it’s about how much you are putting your business at risk by not taking care of basic things such as Telnet or FTP and what price you’ll pay for that.