Mimari ve çalışma modeli
Kerberos, kullanıcının parolasını her hizmete göndermek yerine KDC'den alınan süreli biletlerle kimliği kanıtlar. İstemci önce TGT, ardından hedef hizmetin SPN'i için servis bileti alır. KDC, SPN'i bir hesap ve anahtarla eşler; hizmet de bileti kendi anahtarıyla açar. Bu nedenle DNS adı, SPN kaydı, hizmet hesabı, keytab ve saat aynı kimlik zincirinin parçalarıdır.
Tarayıcıda sürekli kimlik bilgisi isteme, KRB_AP_ERR_MODIFIED, Principal unknown veya Clock skew too great belirtileri aynı kök nedene işaret etmez. Yinelenen SPN, KDC'nin doğru hizmet hesabını seçmesini engelleyebilir. Yanlış hesaptaki tekil SPN ise istemciye bilet verir fakat hizmet bileti açamaz. Saat farkı biletin henüz geçerli değil ya da süresi geçmiş görünmesine yol açar; varsayılan toleransı büyütmek zaman senkronizasyonunu düzeltmez.
Teşhiste önce istenen URL ve DNS kanonik adını kaydedin. İstemcinin gerçekten Kerberos denediğini, hangi SPN için bilet aldığını ve biletin başlangıç/bitiş zamanını doğrulayın. Ardından SPN'i orman genelinde arayın, hizmetin çalıştığı hesabı ve keytab sürümünü karşılaştırın. Son olarak NTP/chrony durumunu ve KDC saatini ölçün; bilet önbelleğini yalnız kanıt topladıktan sonra yenileyin.
Düzeltme değişikliklerini küçük tutun. SPN'i silip yeniden eklemeden önce sahip hesap, hizmet başlangıç kimliği ve yük devretme düğümlerini belgeleyin. `setspn -S` yinelenen kaydı kontrol ederek ekleme yapar; `-A` yerine bu davranış tercih edilmelidir. Linux hizmetlerinde keytab principal ve KVNO değerleri KDC ile uyumlu olmalıdır. Parola veya anahtar yenilemesinden sonra eski keytab kullanan düğümleri ayrı izleyin.
- 1İstemci ve DNS adı
- 2KDC'den TGT ve servis bileti
- 3SPN sahibi ve hizmet anahtarı
- 4Uygulama oturumu ve denetim kaydı
Tasarım parametreleri
- Hedef kimlik
- Kullanıcının yazdığı FQDN, DNS CNAME sonucu ve uygulamanın beklediği SPN'i birlikte kaydedin.
- SPN tekilliği
- SPN'in orman içinde tek hesaba bağlı olduğunu ve hizmetin gerçekten o hesapla çalıştığını doğrulayın.
- Zaman sınırı
- İstemci, KDC ve sunucunun UTC farkını ölçün; yalnız yapılandırılmış toleransın altında olup olmadığına bakmayın.
- Anahtar sürümü
- Keytab içindeki principal, şifreleme türü ve KVNO'yu KDC kaydıyla eşleştirin.
- Geri alma
- SPN veya hizmet hesabı değişikliğinden önce eski sahipliği ve çalışan bilet örneğini kaydedin.
Hesap ve uygulama örneği
`https://erp.example.com` isteği `HTTP/erp.example.com` SPN'i için bilet alıyor fakat iki hesapta aynı SPN bulunuyorsa KDC seçimi güvenilir değildir. `setspn -F -Q HTTP/erp.example.com` ile sahipleri bulun, hizmet hesabını süreç yöneticisinden doğrulayın ve yanlış kaydı kontrollü kaldırın. Ardından yeni oturumda bilet alıp sunucu olayını aynı zaman aralığında eşleyin.
İstemci 09:00 UTC, KDC 09:06 UTC gösteriyorsa altı dakikalık fark tipik beş dakikalık toleransı aşar. Toleransı on dakikaya çıkarmak görünür hatayı azaltabilir fakat bilet tekrarını ve diğer zaman bağımlı denetimleri zayıflatır. Önce zaman kaynağı, senkronizasyon durumu ve sanal makine host clock davranışını düzeltin; sonra yeni TGT ile yeniden test edin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Windows/AD
setspn -F -Q HTTP/erp.example.com
setspn -F -X
klist get HTTP/erp.example.com
# Linux/MIT Kerberos
env KRB5_TRACE=/dev/stdout kvno HTTP/erp.example.com
klist -e
klist -k -e /etc/krb5.keytab
chronyc trackingHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| KRB_AP_ERR_MODIFIED | Bilet yanlış hesaptaki anahtarla üretildi veya hizmet eski keytab kullanıyor olabilir. | SPN sahibini, hizmet hesabını, KVNO'yu ve aynı düğümdeki keytabı karşılaştırın. |
| Server not found in Kerberos database | İstenen SPN yok, farklı adla kayıtlı veya yanlış realm'e yönleniyor olabilir. | KRB5_TRACE ile istenen principalı görün; DNS adı ve SPN sorgusunu eşleştirin. |
| Clock skew too great | İstemci, sunucu ya da KDC zamanı tolerans dışında olabilir. | UTC saatlerini, chrony/NTP kaynağını ve son senkronizasyon hatasını kaydedin. |
| NTLM'e sessiz geri dönüş | Kerberos bileti alınamamış fakat uygulama başka mekanizmayla çalışmış olabilir. | İstemci bilet önbelleğini ve sunucu kimlik doğrulama paketini inceleyin. |
Kabul ve doğrulama kontrolleri
- İstenen FQDN ve gerçek DNS hedefini kaydedin.
- KRB5_TRACE veya istemci olaylarıyla talep edilen SPN'i doğrulayın.
- SPN'i etki alanı ve orman genelinde yinelenen kayıt için tarayın.
- Hizmet hesabı, keytab principal ve KVNO değerini eşleştirin.
- İstemci, KDC ve sunucu UTC farkını ölçün.
- Yeni oturumda servis bileti ve uygulama kaydını aynı işlemle doğrulayın.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.