VPN bağlanıyor, ancak SQL Server Windows kimlik doğrulamasını reddediyor

Tüneller açılıyor, sunucular ping'e yanıt veriyor ve veritabanı oturum açma hâlâ bir kimlik doğrulama hatasıyla başarısız oluyor. Bu bileşim VPN bağlantılarında yaygındır ve ağın bozuk olduğu anlamına nadiren gelir, çünkü erişilebilir bir dinleyici ile kabul edilmiş bir oturum açma iki farklı sonuçtur. Ağ geçidini tatmin eden kimlik, veritabanı istemcisinin sunduğu kimlik olmak zorunda değildir. Hangi hesabın geldiğini bulmak işin tamamıdır.

Belirti: erişilebilir sunucu, reddedilen oturum açma

Bir zaman aşımı, paketin hiçbir dinleyiciye ulaşmadığını söyler. Bir kimlik doğrulama hatası, dinleyicinin yanıt verip kimlik bilgilerini reddettiğini söyler. Bu iki mesaj sizi farklı ekiplere gönderir ve onları karıştırmak, hiçbir zaman sorun olmayan güvenlik duvarı kurallarına bir gün harcatır.

Hata başarısız bir oturum açma olduğunda, bağlantı noktalarına bakmayı bırakın. Geriye kalan soru, istemcinin hangi Windows kimliğini sunduğu, sunucunun bu kimliği kabul edip etmediği ve bunun izni olan bir veritabanı kullanıcısına çözülüp çözülmediğidir.

İki kimlik, tek tünel

VPN hesabı ağ geçidinde kimlik doğrular ve çoğu kurulumda orada biter. Veritabanı istemcisi ayrıca bir Windows belirteci sunar; bu belirteç onu çalıştıran süreçten alınır ya da bağlantı dizesi istiyorsa bir SQL oturum açma sunar. Ağ geçidinde yerel bir VPN kullanıcısının SQL Server'ı barındıran etki alanıyla hiçbir ilişkisi yoktur ve tünel böyle bir ilişki oluşturmaz.

Kişisel bir makineyi VPN'e bağlamak onu etki alanına da katmaz. Yerel bir hesabı yeniden adlandırıp parolasını bir etki alanı kullanıcısıyla eşleştirmek bir kayıt yordamı değildir ve etki alanı denetleyicisinin o kullanıcı olarak kabul etmeyeceği bir belirteç üretir.

Bazı yerel Windows uzaktan erişim istemcileri, profilleri bu şekilde yapılandırıldığında ağ kaynakları için VPN kimlik bilgilerini yeniden kullanabilir. Bu davranış belirli bir istemciye ve profile aittir, genel olarak VPN bağlantılarına değil, bu yüzden varsaymak yerine kullanılan istemci için doğrulayın.

İstemcinin istediği modu okuyun

Bağlantı dizesi, istemcinin hangi kimlik doğrulama yolunu izleyeceğine karar verir. Tümleşik güvenlik Windows belirtecini kullanır; bir kullanıcı ve parola çifti bir SQL oturum açma seçer. Bunlar sunucu yapılandırmasında ayrı modlardır ve belirli bir bağlantı denemesi için yalnızca biri etkinleştirilebilir.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Windows oturum açma başarısız olduğu için SQL oturum açmaya geçmek, kimlik sorusunu gizleyen bir geçici çözümdür ve genellikle yine de yeni bir oturum açma ve parola oluşturulmasını gerektirir. Kurulum Windows kimlik doğrulaması gerektiriyorsa modu koruyun ve kimlik yolunu onarın. SQL oturum açmanın da kendi izinlerine ihtiyacı vardır, bu yüzden geçici çözüm bakımı yapılacak ikinci bir hesap satın alır.

Hangi uygulamanın bağlandığını da doğrulayın. Sistem hesabı olarak çalışan bir hizmet, zamanlanmış bir görev ve etkileşimli bir sorgu penceresi aynı makinede üç farklı belirteç sunabilir ve yalnızca sonuncusu kullanıcının whoami çalıştırdığında gördüğüyle eşleşir.

Sunucuya gerçekte ne gördüğünü sorun

Sunucu hangi oturum açmayı çözdüğünü ve bağlantının nasıl kimlik doğrulandığını size söyleyebilir. Sorguyu incelenen oturumun içinde çalıştırın, çünkü yöneticinin ayrı bir başarılı bağlantısı başarısız istemci hakkında hiçbir şey kanıtlamaz.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

İlk satır, oturumu açan oturum açmayı şu anda yürürlükte olan güvenlik bağlamından ayırır ve bunlar kimliğe bürünme altında farklıdır. İkincisi kimlik doğrulama şemasını adlandırır, böylece KERBEROS, NTLM ve SQL tahmin yerine görünür gerçekler olur. Kerberos beklediğiniz yerde NTLM bildiren bir bağlantı parola sorunu değil, ad çözümleme veya SPN sorunudur.

Hata numarası bunu daha da daraltır. Durum 5 genellikle oturum açma adının hiç çözülmediği anlamına gelir, durum 8 genellikle parolanın eşleşmediği anlamına gelir ve durum 11 kimlik bilgilerinin kabul edildiği ancak sunucuya erişimin başarısız olduğu anlamına gelir. Yöneticiden tüm mesajı değil durumu isteyin, çünkü mesaj tek başına kasıtlı olarak belirsizdir.

Kimlik geldiğinde ve Kerberos hâlâ başarısız olduğunda

Sunucu amaçlanan Windows kimliğini görüyor ve tümleşik kimlik doğrulama hâlâ başarısız oluyorsa sorun takasın kendisidir. Kerberos, SQL hizmet hesabı için kayıtlı hizmet asıl adına ve hizmeti bununla eşleşen bir adla isteyen bir istemciye ihtiyaç duyar. IP adresiyle bağlanmak ad tabanlı bir SPN ile eşleşemez ve bir diğer ad ancak kendisi de kayıtlıysa eşleşebilir. Her şeyden önce istemcinin yazdığı adı kontrol edin, çünkü ana bilgisayar adıyla çalışıp IP ile başarısız olan bağlantı tam olarak bu sorunu tanımlar.

Yöneticiden deneme yanılmayla yinelenen SPN'ler oluşturmak yerine kayıtlı kimliği ve hizmet hesabını gözden geçirmesini isteyin. Yinelenen kayıtlar, özgün sorundan tanımlanması daha zor aralıklı arızalar üretir.

Kimlik doğrulama çalıştıktan sonra oturum açmanın hâlâ bir veritabanı kullanıcısına ve izinlere ihtiyacı vardır. Başarılı bir VPN oturum açma, başarılı bir Windows oturum açma ve belirli bir tabloyu okuma izni üç ayrı sonuçtur ve her biri kayıt kapatılmadan önce kendi kontrolünü hak eder.