Kaynak olarak kullandığımız harici NTP sunucularından biri (şu anda birincil olan) NTP çağrılarına yanıt vermiyor gibi görünüyor. Ne yazık ki, çekirdek yönlendiricimizde (Cisco 6509), NTP işlevselliği beklendiği gibi ikincil NTP harici sunucusuna geçmedi. Sonuç olarak, ana dahili NTP kaynağımız olan çekirdek yönlendiricimiz 2 dakika geç kaldı.

Harici NTP kaynağını şu anda çalışan biri yaparak harici yönlendirici sorununu düzeltmeyi planlıyorum. Merak ediyorum, 2 dakikalık bir değişiklik kullanıcılarımı ve hizmetlerimi ne kadar etkileyecek? Özellikle bu günlerden bu yana, sertifika tabanlı kimlik doğrulamaya büyük ölçüde güveniyoruz.

Biz bir Windows / Cisco mağazasıyız.

Dahili NTP kurulumu:

[Core Router 1 / Cisco 6509]:
iki harici NTP sunucusuna (birincil sunucunun NTP çağrılarına yanıt vermediği) bakıyor

[Core Router 2]:
Core yönlendirici 1 (birincil), çalışan harici yönlendirici (ikincil) ile senkronizasyon

[Diğer Cisco ağ cihazları]:
Çekirdek yönlendirici 1 (birincil), çekirdek yönlendirici 2 (ikincil) ile senkronizasyon

[Etki alanı denetleyicileri]:
Çekirdek yönlendirici 1 ile eşzamanlama

[Tüm Windows istemcileri / sunucuları]:
Etki alanı denetleyicileriyle senkronizasyon

Son derece hassas zaman işleyişi sizin için kritik öneme sahip olmadıkça, saatlerinin 2 dakika kadar değişmesi dışında, kullanıcılarınız için fark edilebilir bir etki olmamalıdır.

Muhtemel istisna, NTP sunucunuzu büyük değişikliklerin bir sonucu olarak "deli" olarak ilan etmeleridir (etkilenen sistemlerde NTP hizmetini saati senkronize etmeye zorlamak için yeniden başlatmanızı gerektirir - ancak bunu olmadan da yapabilirsiniz. bir kesinti).

Bunu düzeltirken, burada birkaç işaretçi daha var:

• Harici NTP kaynaklarına bakan sistemlerinizi , genel NTP havuz projesinden (tercihen coğrafi olarak uygun olanlar ) birkaç (4-5) sunucuya bakacak şekilde yapılandırmalısınız .
  Daha fazla NTP sunucusuna sahip olmak, seçim algoritmasının deliren / çıldırtan ve saatinizi doğru tutanları yok saymasına izin verir.

• Ben işaret ediyorum sizinki gibi bir yapılandırmada Core Router 1ve Core Router 2harici saat kaynaklardan (birbirlerine değil).
  Bu, birbirinden birkaç ms içinde olması gereken bağımsız olarak senkronize edilmiş iki saat verir, ancak yönlendiricilerinizden biri delirirse diğerine zarar veremez.

• Sizinki gibi bir yapılandırmada, BOTH çekirdek yönlendiricilerindeki etki alanı denetleyicilerini işaret ederim (yine bir aşağıya karşı korumak için).
  Eğer çılgınca bir saate karşı korumak istiyorsanız, üçüncü bir yetkili NTP sunucusu eklemelisiniz (veya yönlendiricilerinizden birini iki kez listelemeli ve aklını kaybeden değil…)

Windows için etki alanı varsayılanları, kimlik doğrulamasının çalışmasını durdurmadan önce sürenin +/- 300 saniye kapalı olmasına izin verir, bu nedenle iyi olursunuz. Aşağıda , alan adı düzeyinde bir GPO ile çarpıklığa karşı toleransınızı nasıl değiştireceğinizden bahseten konu hakkında oldukça kapsamlı bir makale var . Hiç de var Computer Configuration> - Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Bununla birlikte, yetkili zaman kaynağınız (genellikle bir Windows etki alanında PDC öykünücüsü rolüne sahip olan Etki Alanı Denetleyicisi) ntpgibi harici bir kaynakla senkronize olmanız gerekir pool.ntp.org. Technet'ten daha fazla bilgi, burada .

Ve diğer cevaba yanıt olarak, bu kesinti gerektirmez. Yetkili zaman kaynağınızı yeniden işaretlediğinizde, etki alanına katılmış diğer bilgisayarlar da kendilerini eşitler.

EDIT: @ voretaq7 bahsettiğinden beri, sadece bir sistem dışında bir zaman kaynağı, PDC emülatör görmek olduğunu belirtmek gerekir. Ağ donanımı da dahil olmak üzere tüm cihazlar senkronize olur. Bunun daha iyi bir düzenleme olduğunu görüyoruz, çünkü ağ iletişimi zaman eğriliği nedeniyle kimlik doğrulamayı reddetmeyecek, ancak Kerberos'u (hepsi bizim için) kullanan etki alanına katılmış bilgisayarlar olacaktır. Bu nedenle, ağ donanımımızda doğru zamana sahip olmak özellikle önemli değil, ancak Windows sistemlerimizde iki katına çıkıyor, çünkü saat çalışan yazılımlarımız için bir Windows sunucusunda da saat çalışan yazılımımızı çalıştırıyoruz.

Windows istemcilerinde oturum açmakta sorun yoktur. Maximum tolerance for computer clock synchronizationPolitikanın açıklaması bu günlerde oldukça yanlış.

Ciddi şekilde yanlış bir saati olan bir istemci sunucudan saatler arasında eğriliği kuran bir yanıt alacaktır - kimlik doğrulama daha sonra normal bir şekilde ilerler (istemci görünür saat eğimini hesaba katacak şekilde ayarlayarak).

Açıklama bir şey için doğru; politika yine de tekrar saldırıları için zamanlayıcıyı etkili bir şekilde ayarlar - ancak yasal trafik açısından iletişim büyük saat eğrilerine karşı sağlamdır.

Daha fazla bilgi için bu MS KB makalesine bakın .

Çekirdek cisco ekipmanınızdan başka NTP sunucularına bakmayı düşünebilirsiniz: ciddi NTP trafiği, cisco ekipmanında ağ sorunlarına neden olabilecek yüksek bir işlemci yükü verir.

Açıkçası küçük bir kesinti planlayamazsınız, değil mi? Etkilenen tüm sunucularda ntp hizmetini yeniden başlatmak için bir kesinti için itmek. Bu mümkün değilse, bir süre beklemek zorundasınız.

(Bunu vortaq7'nin cevabı hakkında bir yorum yapacaktım, ancak birçok insan bu hatayı yaptığı için kendi başına tekrarlamayı hak ettiğini düşünüyorum.)

NTP algoritmasının doğru zamanda doğru bir şekilde birleşmesi için en az 3 (tercihen 4-6) zaman kaynağına ihtiyacınız vardır. NTP'nin yalnızca iki birincil kaynağı varsa ve her ikisinin de önemli miktarda olması durumunda, NTP'nin hangisine güveneceğini bilmesinin bir yolu yoktur.

Bunun anlaşılmasında bana yardımcı olan en büyük yardım, Sun'ın "Sistem Saatlerini Kontrol Etmek ve Senkronize Etmek için NTP Kullanımı, bölüm III: NTP İzleme ve Sorun Giderme" sayfa 9'daki diyagramdı. Oracle Sun'ı satın aldığında bu belge görünmüyor, ancak yine de Wayback Machine'de bulabilirsiniz . Başlık için arama yaparsanız web'de çok sayıda isabet de vardır.