SQL Server 2008 Windows Kimlik Doğrulama Oturum Açma Hatası: Oturum açma, güvenilmeyen bir etki alanından geliyor

Management Studio kullanarak bir SQL Server 2008 Örneğine bağlanmaya çalışırken aşağıdaki hatayı alıyorum:

Giriş başarısız. Oturum açma, güvenilmeyen bir etki alanındandır ve Windows kimlik doğrulaması ile kullanılamaz. (Microsoft SQL Server, Hata: 18452)

SQL Kimlik Doğrulaması kullanarak sorunsuz oturum açabilirim. Bu hatayı birden bire alıyorum. Karışık Mod Kimlik Doğrulamasını açtım.

Bu konuda tecrübesi olan var mı?

Ek Bilgi: Windows 2003 Server'da SQL Enterprise Edition'ın 64-bit sürümü

Bunun olmasının başka bir nedeni de (bana oldu) ... kullanıcının şifresinin süresinin dolması. Gerçek sunucuya uzaktan erişmeyi deneyene ve parolamı değiştirmem istenene kadar bunu fark etmemiştim.

Benim için bu, boş bir drivers/etc/hostsdosyayı düzenlediğimde ve yerel bir web sitesi için bir girdi eklediğimde, ancak eklemeyi ihmal ettiğimde oldu127.0.0.1 localhost

Sorun, elbette Windows hesabının kimliğini doğrulayamayan bir Active Directory Sunucusunun çökmesinden kaynaklanıyordu. Yardımınız için teşekkürler.

Bununla karşılaşan diğer herkes için, bunu ana bilgisayar dosyamda buldum:

127.0.0.1   localhost
127.0.0.1   customname

ve bunun şu olmasına ihtiyacım vardı:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"Sorun, elbette Windows hesabının kimliğini doğrulayamayan kapalı bir Active Directory Sunucusundan kaynaklanıyordu"

Tabii ki "değil - çünkü AD mevcut değilse, Kerberos kimlik doğrulaması NTLM'ye geri döner (etki alanı hesabı kimlik bilgileri yerel olarak önbelleğe alınır, AD / Kerberos mevcut olmasa bile onunla oturum açılabilir). bu başarısızlığın gerçekleşmesi için eşzamanlı koşullar:

• SQL Server yerel değil (başka bir makinede)
• Güven "yalnızca Kerberos" olarak yapılandırılmıştır

veya diğer özel güvenlik ağı / sunucu / AD / makine yapılandırmaları

Yerel makinemdeki bir sunucu örneği için bu sorunu yaşadım ve bunun, ana bilgisayar dosyamda "localhost" dışında bir şeyle 127.0.0.1'e işaret ettiğim için olduğunu gördüm. Benim durumumda bu sorunu çözmenin iki yolu var:

1. Hosts dosyasında 127.0.0.1'e işaret eden rahatsız edici girişi temizleyin
2. Ana bilgisayar dosyasında 127.0.0.1'e işaret eden diğer ad yerine "localhost" kullanın

* Bu sadece yerel kutumda sql sunucu örneğini çalıştırdığımda ve ona aynı makineden erişmeye çalışırken benim için çalıştı.

Başka bir etki alanında \ kullanıcı üzerinde bir VPN'e bağlı olmadığınızdan emin olun . Ya da tam tersine emin olun vardır o gerekenleri ise bağladı.

Geri döngü denetimi ayarını devre dışı bırakan makinede bu sorunu düzelttim:

1. Windows kayıt defterini düzenleyin: Başlat -> Çalıştır> Regedit
2. Şuraya gidin: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. "DisableLoopbackCheck" adlı bir DWORD değeri ekleyin
4. Bu değeri 1 olarak ayarlayın

RUNAS komutunu kullanarak farklı bir geçerli giriş kullanmayı deneyin

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Benim için bunun nedeni, kullanmak istediğim rollere sahip hesabı SQL Veritabanına eklemememdi. Ve ayrıca kopyalama yapıştırma sorunu kilitleme hesabı yoluyla kötü bir şifre girişimleri nedeniyle.

Tamam, benden tamamen dışarıda cevap. Bu hatayı VM VirtualBox üzerinde barındırılan bir geliştirme ortamından alıyordum. Üç sunucu; SharePoint, SQL DB ve Etki Alanı Denetleyicisi. SharePoint sunucusu yapılandırma veritabanına bağlanamadı. SA hesabını kullanarak Sql kimlik doğrulaması için ODBC aracılığıyla hala bağlanabiliyordum ancak Windows kimlik doğrulamasını kullanamıyorum. Ancak bu kullanıcı, SQL sunucusunun kendisinde SSMS'de mutlu bir şekilde oturum açacaktır. ODBC'den de daha iyi bir hata mesajı aldım ve ayrıca sql sunucusundaki başarısız oturum açma mesajlarını kontrol ederek:

select text from sys.messages where message_id = '18452' and language_id = 1033

Bunun için kredi alamıyorum çünkü Kurumsal Sistem Yöneticilerimizden birinden yardım istedim ve ona gönderdiğim birkaç ekran görüntüsüne bakarak yaklaşık 5 dakika içinde teşhis koydu. Sorun, Etki Alanı Denetleyicisi'nin saatinin yanlış ayarlanmış olmasıydı! İnanamadım. Sunucular, Yalnızca Ana Bilgisayar ağı için ayarlanmıştır, bu nedenle saati senkronize etmek için internetiniz yoktur. Bu aynı zamanda sistemin çalıştığını bildiğim halde daha önceki bir anlık görüntüye dönmenin neden sorunu çözmediğini de açıklıyor.

Düzenleme: Konuk Eklemelerini sunucuya yüklemek, konuk saatini ana bilgisayarla senkronize eder.

JTDS sürücüsünde USENTLMV2 adlı ve varsayılan olarak false değerine ayarlanmış bir ayar vardır. Bunu db yazılımımda (DBVisualizer) 'true' olarak ayarlamak sorunu çözdü.

Bunu görebileceğiniz başka bir senaryo, parolanızı değiştirirken zaten oturum açmış olan bir SSMS oturumundan başka bir SQL sunucusuna bağlanmaya çalıştığınız zamandır. Olay dizisi aşağıdaki gibi olabilir:

1. RDP'den Sunucu-A'ya (SQL Sunucunuz), SSMS'yi açın ve oturum açın
2. Aynı etki alanında Sunucu-B'ye RDP ve parolanızı değiştirin
3. Sunucu-A'da RDP oturumuna dönün ve SSMS aracılığıyla mevcut bir AlwaysOn kullanılabilirlik grubuna başka bir DB eklemeyi deneyin. Eşlemelere bağlanırken "güvenilmeyen etki alanı" -login hatası alıyorsunuz

Çözmek için oturumu kapatın ve tekrar oturum açın

Yerel olarak kullandığınız kullanıcı adı konusunda yanıltıcı olabilirsiniz . Windows 10 Home'daki durumum buydu. Denetim masasında kullanıcılara baktığımda usrpc01 adını görüyorum . Ancak yazdığımda net config workstation, kullanıcının adının spc01 olduğu anlaşılıyor . Birisi kullanıcıyı yeniden adlandırmış gibi görünüyor, ancak dahili ad değişmeden kaldı.

Windows kullanıcı adını (ve altındaki klasör adını C:\Users, orijinal dahili adı da ifade eder) nasıl düzelteceğimi bilmeden , db sunucuma yeni bir kullanıcı hesabı ekledim.

Bir etki alanı hesabından bir SQL Server 2008'e giriş yapmaya çalışıyorum. SQL Server 2008, etki alanının parçası olmayan farklı bir çalışma grubu bilgisayarında barındırılır. Kulağa garip gelse de, SQL Server 2008'in çalıştığı çalışma grubu sunucusunda, Sistem Özellikleri | Bilgisayar Adı (sekme) | Değiştir (düğme) | Bilgisayar Adı Değişikliği | Daha fazla ... (düğme) ve "Bu bilgisayarın Birincil DNS son ekini" girin (boştu, bu nedenle ağınız için istediğiniz son eki girin) ve "Etki alanı üyeliği değiştiğinde birincil DNS son ekini değiştir" kutusunu işaretleyin. Bu, SQL Server 2008'de oturum açarken Windows Kimlik Doğrulama işleminin tamamlanmasına izin verdi.

Bunu modern Windows'ta çalıştırmak için netonly'yi kullanmak zorunda kaldım:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Başka bir neden> birisi varsayılan SQL kullanıcısının parolasını değiştirdi

Bu, birkaç dakika önce yeni bir etki alanı denetleyicisine geçerek başıma geldi ...

Altında ana bilgisayar dosyasında yanlış giriş yaptım C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Aşağıdaki gibi giriş yaptığınızdan emin olun

127.0.0.1   localhost
127.0.0.1   localhost   servername

Bir SQL Server örneği için "127.0.0.1" i gösteren bir takma ad kullanıyordum. Bunun yerine "localhost" olarak değiştirmek hile yaptı.

Sql Sunucunuz bir etki alanının parçası olmayan bir sunucuda çalışıyorsa ve bağlantı dizesinde Integrated Security = True ile tam olarak nitelendirilmiş bir etki alanı adı (örn. Xyz.mypc.com) kullanıyorsanız, ikisinden birini kullanmaya geçmeniz gerekebilir. IP adresi, MakineAdı (SERVER01) veya yerel olarak barındırılması durumunda nokta (.).

Bu benim için çalıştı, fqdn'yi kullanmak yukarıdaki hataya neden oldu.

Windows kimlik doğrulamasını etkinleştirmek için her iki bilgisayarın da aynı etki alanında olması gerekir. yönetim stüdyolarının mevcut kimlik bilgilerini geçmesine ve sql kutusunda kimlik doğrulamasına izin vermek için

Benim için, Etki Alanından bağlantıyı kesmem (çalışma grubunu / etki alanını değiştirmem) ve yeniden bağlanmam gerekiyor.

Ve başka bir olası neden: DB Sunucusunda yeni oluşturulan yerel Hesap, "Kullanıcı bir sonraki Oturum Açmada Parolayı değiştirmelidir" Bayrak ayarına sahipti.

Benim için sorunu şu şekilde çözdü: Ağ bağlantısının özellikleri: "İnternet Protokolü Sürüm 4 (TCT / IPv4)" seçeneğine tıklayın. "Özellikler" düğmesini tıklayın. "Gelişmiş" düğmesini tıklayın. "DNS" sekmesini seçin. "Bu bağlantı için DNS son ekindeki" metni silin.

Ben de SQL sunucusuna uzaktan bağlanamadım. Aynı etki alanında hem SQL sunucusu hem de uzak sunucu. Ve birkaç gün önce benden şifre değişikliği talep edilmişti. Hem SQL sunucusunu hem de SQL sunucusuna erişmeye çalıştığım uzak sunucuyu yeniden başlatmak benim için hile yaptı.

Bizim durumumuzda, geliştiricinin uygulama havuzunu kendi hesabı altında çalıştırdığı ve şifresini sıfırladığı ancak uygulama havuzunda değiştirmeyi unuttuğu gerçeğiydi. Yaa ...

Benim durumumda, sunucu etki alanı denetleyicisinde devre dışı bırakılmıştı. Active Directory'deki COMPUTERS OU'ya girdim, sunucuya sağ tıkladım, etkinleştirdim, ardından SQL sunucusundan bir gpupdate / force yaptım. Biraz zaman aldı ama sonunda işe yaradı.

Benim durumumda, ana bilgisayar dosyasında, makine adı eski IP ile sabit kodlanmıştır. Eski IP'yi yenisiyle değiştiriyorum, sorun çözüldü.

Ana bilgisayar dosyası konumu

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Yapılan değişiklikler 159.xx.xx.xxx MachineName

Yukarıdakilerin hiçbiri benim için işe yaramadı. Yapmam gereken şuydu: Oturum açma ekranında SQL Server Management Studio'da, Seçenekler >> öğesini seçin Ağ bölümünde Ağ protokolünü Named Pipes olarak değiştirin.

Ayrıca, <default>ayarın çalışmasını sağlamak için yapmam gereken şey kablosuz ağı devre dışı bırakmaktı (makine aynı zamanda kablolu lan'a da bağlıydı).

Benim düzeltmem, web.config dosyasını SQL Bağlantısı için yeni sunucu adıma uygun olacak şekilde değiştirmekti (BT Güvenliği, geliştirme kutumda bir netdom yeniden adlandırması yapmıştı.