SQL Server VPN üzerinden neden hâlâ NTLM'e düşüyor?

Kerberos doğru hizmet adını, doğru hesaptaki SPN'yi ve istemcinin alabileceği bir bileti gerektirir. Herhangi bir şeyi değiştirmeden önce auth_scheme sütununu okuyun.

Bağlantınız çalışıyor, oturum açma kabul ediliyor ve herkes Kerberos beklerken SQL Server NTLM kullanıyor. Bu sonuç bir VPN kusuru değil, çünkü tünel yalnızca bir yol sağlar; şemayı istemcinin istediği ad, dizinde kayıtlı olan asıl ve istemcinin gerçekten alabildiği bilet belirledi. Üç koşul aynı anda geçerli olmalıdır ve hangisinin geri çekildiğini oturumun kendisi söyler. Birisi hizmet asıl adını düzenlemeden önce bunu okuyun.

Oturum, gerçekten aldığınız şemanın adını verir

Kimlik doğrulama şeması bir sunucuya veya tünele değil bir bağlantıya aittir, bu yüzden denetim sizi ilgilendiren oturumun içinde çalışmalıdır. Aşağıdaki sorguyu raporu üreten aynı istemciden, araçtan ve hesaptan yürütün ve sonucun yanına hedef adı ve taşımayı not edin.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Veritabanı ana bilgisayarındaki yerel bir SSMS penceresinden gelen satır tamamen farklı bir bağlantıyı tanımlar, bu nedenle sorgu istemci tarafından yürütülmelidir. Çıktıyı zaman damgasıyla kaydedin, çünkü onu okuyacak bir sonraki kişi ne zaman alındığını soracaktır. Birden çok uygulama tek bir uç noktayı paylaşıyorsa her birinden örnek alın, çünkü iki uygulama arasındaki veri kaynağı farkı çoğu zaman hikâyenin tamamıdır.

Birinci koşul: ad SPN ile eşleşiyor mu?

Kerberos adlandırılmış bir hizmetin kimliğini doğrular, bu yüzden istemci dizinden belirli bir asıl için bilet ister. TCP sağlayıcısı için belgelenen biçim MSSQLSvc/ ve ardından tam nitelikli ana bilgisayar adı, varsayılan örnek için ise bağlantı noktası gelir. Adlandırılmış örnek MSSQLSvc/db01.corp.example:SQLPROD kaydeder; burada son ek sayı yerine örnek adıdır. Dinleyiciye bir takma ad, başka yerde çözülen bir CNAME veya çıplak bir IP adresi üzerinden ulaşmak istenen adı değiştirir ve eşleşen aslı olmayan isteğin geri verecek bileti yoktur.

Bu yüzden bir uygulama bir ağda çalışır ve diğerinde geri düşer: bir DNS yanıtı, takma ad kaydı veya hosts girdisi istemcinin kullandığı adı değiştirdi. Kayda dokunmadan önce istenen adı dizinin tuttuğu adla karşılaştırın.

İkinci koşul: SPN doğru hesapta mı?

SPN, SQL hizmetini çalıştıran hesaba ait olmalıdır; istemcinin hesabına veya yanlışlıkla bir bilgisayar nesnesine değil. SQL Server, hizmet hesabının bunları yazma izni olduğunda başlangıçta kendi SPN'lerini kaydedebilir; bu kullanışlıdır ve hizmet hesabı değiştirildikten sonra nasıl bir kopyanın ortaya çıktığını da açıklar.

Dizine beklediğiniz adı sorun, ardından hesabın gerçekte neye sahip olduğunu listeleyin. Hangi nesnenin girdiyi tuttuğu, adın ormanda bir yerde var olup olmadığından daha önemlidir. Uyuşmazlık, oturum açmanın hiçbir zaman sorun olmadığı anlamına gelir ve Microsoft'un SPN kılavuzu biçimleri ve bir etki alanı yöneticisinin girdiyi oluşturması gereken durumları belgeler.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Başka bir girdi eklemek güvenli bir deney değildir. Bir kopya veya çakışan kayıt, çalışan istemcileri bozabilir, bu yüzden değişiklikten önce sahipliği inceleyin ve sonrasında yeniden denetleyin.

Üçüncü koşul: istemci bir bilet alabiliyor mu?

İstemci bir etki alanı denetleyicisine ulaşamıyorsa veya kullanılabilir bir kimlik bilgisi bağlamı yoksa doğru SPN işe yaramaz. Değiş tokuş VPN üzerinden KDC ve DNS gerektirir ve yalnızca SQL bağlantı noktasını yönlendiren bir tünel tam olarak bu adımda başarısız olur. Erişilebilirlik, önlerindeki güvenlik duvarından değil, aynı makineden ve aynı hesaptan test edilmelidir.

Bilet önbelleğini makinede ve uygulamayı çalıştıran hesabın altında inceleyin. Yükseltilmiş bir pencereden alınan makine çapında liste, başka bir kullanıcı olarak çalışan bir hizmet hakkında hiçbir şey söylemez ve o kullanıcı için boş bir önbellek bir bulgudur, sıkıntı değil.

klist
klist -li 0x3e7

Ardından geri düşüşün ne yapabileceğine karar verin. İlke Kerberos gerektiriyorsa NTLM açıkça reddedilmelidir, çünkü sessiz bir geri düşüş bir yapılandırma hatasını gereksinimi ihlal eden çalışan bir bağlantıya dönüştürür. NTLM bazı uygulamalar için kabul edilebilir kalıyorsa onları adlandırın ve her NTLM oturumunu olay olarak görmeyi bırakın.

Başlatıcıyı değiştirmek tek bir değişkendir, düzeltme değil

SSMS'i başka bir kimlik bilgisiyle başlatmak, istenmeyen bir giden kimliği iyileştirebilir; bu gerçek bir sorun sınıfıdır. Hedef ad, kayıt veya bilet yolu hakkında hiçbir şey kanıtlamaz ve sunucunun kabul ettiğini değiştirmez.

Karşılaştırmayı kontrollü tutun: aynı uç nokta, aynı sağlayıcı, bilinen bir yürütme bağlamı, ardından şemasını incelediğiniz yeni bir bağlantı. Kabul edilen oturum açmayı ve veritabanı izinlerini ayrı ayrı doğrulayın, çünkü erişim ve kimlik doğrulama farklı nedenlerle başarısız olur.

Kerberos zorunlu olduğunda ilk yolun neden geri düştüğünü kaydedin, tek bir düzeltme uygulayın ve sorguyu aynı istemciden yeniden çalıştırın. Başlatıcı değişikliğinden sonra başarılı bir sorgu erişimin kanıtıdır ve kimlik doğrulama gereksiniminin karşılandığının kanıtı henüz değildir.

İlgili makaleler