SQL Server 18456 Hatası: Giriş Başarısız Durum Kodunu Nasıl Okursunuz?

SQL Server’daki 18456 hatası, bir oturum açma denemesinin reddedildiğini bildirir; tek başına “parola yanlış” anlamına gelmez. İstemci tarafındaki ileti güvenlik amacıyla ayrıntıyı gizleyebilir. Teşhis için aynı zamandaki SQL Server Error Log kaydındaki State kodunu, bağlanılan örneği ve istenen veritabanını birlikte kontrol edin.

Önce doğru sunucuya bağlandığınızı doğrulayın

Bağlantı dizesindeki sunucu adı, varsa örnek adı ve veritabanı adını kontrol edin. Geliştirme, test ve üretim ortamlarında benzer sunucu adları varsa yanlış örneğe bağlanmak sık görülen bir nedendir. Uygulamanın gerçek bağlantı dizesi ile SSMS’te elle denediğiniz bağlantının aynı hedefi kullandığından emin olun. Hedef veritabanı çevrimdışı, yanlış yazılmış veya oturum açan hesabın varsayılan veritabanı olarak artık kullanılamıyor olabilir.

State kodu hangi yönde araştırma yapacağınızı gösterir

Yetkili bir yönetici Error Log’da aynı saat ve kullanıcı için görünen ayrıntıyı incelemelidir. Microsoft’un hata tablosundaki örnekler arasında State 2 veya 5 geçersiz kullanıcı adını; State 6, Windows hesap adının SQL Authentication ile gönderilmesini; State 7, devre dışı oturum açma veya parola sorununu; State 8 yanlış parolayı; State 18 parola değiştirme gereğini işaret edebilir. State 11 ve 12, kimliğin tanındığı ancak sunucu erişiminin başarısız olduğu durumlarda görülebilir. State 38 veya 46, istenen veritabanına erişim/bulma sorununa işaret edebilir. State 58 ise yalnızca Windows Authentication açıkken SQL Authentication denemesini gösterebilir. Bunlar başlangıç ipuçlarıdır; logdaki tam neden ve sunucu yapılandırması belirleyicidir.

Hata kaydındaki kullanıcı adı etki alanı öneki içeriyorsa Windows hesabı ile SQL login’ini ayırt edin. Windows Authentication beklenen uygulamada connection string’in SQL kullanıcı adı ve parola yollamadığını doğrulayın. Servis veya zamanlanmış görev, masaüstünde oturum açmış kullanıcıdan farklı bir hesapla çalışıyor olabilir.

Kimlik doğrulama modunu gelişigüzel değiştirmeyin

Mixed Mode’a geçmek bazı senaryolarda çözüm olabilir, ancak bu sunucunun güvenlik ve bakım politikasını değiştirir. Önce uygulamanın hangi kimlik doğrulamayı kullanması gerektiğini DBA ile belirleyin; ardından yalnızca gerekli login’i etkinleştirin veya izin verin. SQL Authentication açılacaksa güçlü parola, erişim sınırı ve parola saklama politikası da değerlendirilmelidir. Hata loglarını herkese açık yere koymayın; kullanıcı adları, sunucu adları ve istemci bilgileri hassas olabilir.

Kontrol sırası

• Bağlantı dizesindeki sunucu, örnek ve veritabanı doğru mu?
• Error Log’daki State ve “Reason” ne diyor?
• Uygulama SQL Authentication mı, Windows Authentication mı bekliyor?
• Login var, etkin ve hedef veritabanında yetkili mi?
• Uygulamanın çalışma hesabı test ettiğiniz hesapla aynı mı?

Microsoft’un MSSQLSERVER_18456 açıklaması ve bağlantı/kimlik doğrulama sorun giderme rehberi durum kodlarını bağlamıyla açıklar. Lisans seçenekleri için SQL Server 2022 Standard sayfasına; yedekleme farkları için Simple ve Full kurtarma modeli rehberine bakın.