Hedef asıl adı yanlış. SSPI içeriği oluşturulamıyor

A makinesinden SQL Server'ı çalıştıran makine B'ye bir SQL Server bağlantısı kurmakta zorlanıyorum.

Google'da kapsamlı bir şekilde araştırdım ve bulduğum hiçbir şey işe yaramadı. Ayrıca bunu çözme sürecinde size adım adım yol göstermezler.

Kerberos kullanmıyoruz, ancak yapılandırıldığında NTLM kullanıyoruz.

İlgili makineler şunlardır (xx, güvenlik amacıyla makine adlarından bazılarını gizlemek için kullanılır):

• xxPRODSVR001 - Windows Server 2012 Etki Alanı Denetleyicisi
• xxDEVSVR003 - Windows Server 2012 (Bu makine hatayı oluşturuyor)
• xxDEVSVR002 - Windows Server 2012 (Bu makinede SQL Server 2012 çalışıyor)

Aşağıdaki SPN'ler DC (xxPRODSVR001) üzerine kayıtlıdır. Güvenlik nedeniyle alanı yyy ile gizledim:

CN = xxDEVSVR002, CN = Computers, DC = yyy, DC = local için Kayıtlı ServicePrincipalNames:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

CN = xxDEVSVR003, CN = Computers, DC = yyy, DC = local için Kayıtlı ServicePrincipalNames:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Şimdi, eğer SQL Server hata mesajı daha açıklayıcı olsaydı ve bana bağlanmaya çalıştığı asıl adı söyleseydi, bunu teşhis edebilirdim.

Öyleyse biri bana bunu nasıl çözeceğime adım atabilir mi yoksa sağladığım şeyde yanlış olan herhangi bir şey görebiliyor musunuz?

Daha fazla hata ayıklama bilgisi oluşturmaktan memnuniyet duyarım, sadece neye ihtiyacınız olduğunu söyleyin.

Bu sorunu üzerinde çalıştığım bir ASP.NET MVC uygulamasıyla yaşadım.

Yakın zamanda şifremi değiştirdiğimi fark ettim ve çıkış yapıp tekrar giriş yaparak şifremi düzeltebildim.

Windows Kimlik Doğrulaması kullanarak SQL Server Management Studio aracılığıyla bağlanırken bu hatayı aldım. Parolamın süresi dolmuştu ancak henüz değiştirmedim. Bir kez değiştirildikten sonra, makinenin yeni kimlik bilgilerimi kullanarak çalışması için oturumu kapatıp tekrar oturum açmam gerekti.

Integrated Security=trueBu parametreyi bağlantı dizesinden kaldırmayı ayarlamayı deneyin .

ÖNEMLİ: @Auspex kullanıcısının yorum yaptığı gibi,

Windows kimlik bilgilerinizle oturum açmaya çalışırken hata oluştuğundan, Integrated Security'nin kaldırılması bu hatayı önleyecektir. Maalesef çoğu zaman Windows kimlik bilgilerinizle oturum açabilmek istersiniz.

Windows kimlik doğrulamasını denerken aynı hatayı alıyordum. Kulağa gülünç geliyor, ancak bir başkasına yardımcı olma ihtimaline karşı: bunun nedeni, hala oturum açarken (!) Alan hesabımın bir şekilde kilitlenmesiydi. Hesabın kilidini açmak sorunu çözdü.

Windows 10'da parola yerine PIN ile oturum açıyordum. Oturumu kapatıp parolamla tekrar oturum açtım ve Management Studio aracılığıyla SQL Server'a girebildim.

SSPI içerik hatası kesinlikle kimlik doğrulamanın Kerberos kullanılarak yapılmaya çalışıldığını gösterir .

Kerberos kimlik doğrulaması SQL Server'ın Windows Kimlik Doğrulaması , bilgisayarınız ile ağ etki alanı denetleyiciniz arasında güçlü bir ilişki gerektiren Active Directory'ye dayandığından , işe bu ilişkiyi doğrulayarak başlamalısınız.

Aşağıdaki Powershell komutu Test-ComputerSecureChannel aracılığıyla bu ilişkiyi hızlı bir şekilde kontrol edebilirsiniz .

Test-ComputerSecureChannel -verbose

Yanlış döndürürse , bilgisayarınızın Active Directory güvenli kanalını onarmalısınız, çünkü bu olmadan bilgisayarınızın dışında etki alanı kimlik doğrulaması mümkün değildir.

Aşağıdaki Powershell komutu ile Güvenli Bilgisayar Kanalınızı onarabilirsiniz :

Test-ComputerSecureChannel -Repair

Güvenlik olay günlüklerini kontrol edin, kerberos kullanıyorsanız, kimlik doğrulama paketi ile oturum açma girişimlerini görmelisiniz: Kerberos.

NTLM kimlik doğrulaması başarısız olabilir ve bu nedenle bir kerberos kimlik doğrulama girişimi yapılıyor. Güvenlik olay günlüğünüzde bir NTLM oturum açma girişimi hatası da görebilirsiniz.

Çok ayrıntılı olmasına rağmen, kerberos'un neden başarısız olduğunu bulmaya çalışmak için dev'de kerberos olay günlüğünü açabilirsiniz.

Microsoft'un SQL Server için Kerberos Configuration Manager, bu sorunu hızla tanılamanıza ve düzeltmenize yardımcı olabilir.

İşte okumak için güzel bir hikaye: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Bu en belirsiz hataya başka bir potansiyel çözüm eklemek için The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

SQL Server'a ping atarken çözülen IP'nin Configuration Manager'daki IP ile aynı olduğunu doğrulayın. Kontrol etmek için SQL Server Configuration Manager'ı açın ve ardından SQL Server Network Configuration> Protocols for MSSQLServer> TCP / IP'ye gidin.

TCP / IP'nin etkinleştirildiğinden ve IP Adresleri sekmesinde, ping atarken sunucunun çözdüğü IP'nin buradaki IP ile aynı olduğundan emin olun. Bu benim için bu hatayı düzeltti.

Sorun, bir Windows kimlik bilgileri sorunu gibi görünüyor. Bir VPN ile iş dizüstü bilgisayarımda aynı hatayı alıyordum. Sözde Etki Alanım / Kullanıcı Adım olarak oturum açtım, bu doğrudan bağlanırken başarılı bir şekilde kullandığım şeydir, ancak başka bir bağlantıyla bir VPN'e geçtiğimde bu hatayı alıyorum. Sunucuya ping atabildiğim için bunun bir DNS sorunu olduğunu düşündüm, ancak SMSS'yi kullanıcım olarak Komut isteminden açıkça çalıştırmam gerektiği ortaya çıktı.

örneğin runas / netonly / user: YourDoman \ YourUsername "C: \ Program Files (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

Hem SQL Kutunuzda hem de istemcinizde oturum açın ve şunu yazın:

ipconfig /flushdns
nbtstat -R

Bu işe yaramazsa, istemci makinenizde DHCP'nizi yenileyin ... Bu, ofisimizdeki 2 PC için çalışır.

Sadece bununla karşılaştım ve 2 şey yaparak düzelttim:

1. Https://support.microsoft.com/en-us/kb/811889 sayfasında açıklandığı gibi, ADSI Düzenlemeyi kullanarak hizmet hesabına okuma / yazma servicePrincipalName izinleri verme

2. Daha önce SQL Server bilgisayar hesabında var olan SPN'leri (hizmet hesabının aksine) kullanarak kaldırma

   setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
   

   burada 1234 örneği tarafından kullanılan bağlantı noktası (maden varsayılan bir örnek değildir).

Benim durumumda, SQL Server 2014'ü (geliştirme sunucumda) yeniden başlatmak sorunu çözdü.

İzole edilmiş bir ağdaki bir PC kümesinde IPv6'yı test ediyordum ve IPv4'ü geri aldığımda bu sorunla karşılaştım. Aktif dizinde, DNS'de ve DHCP'de oynuyordum, bu yüzden Kerberos kurulumunu kırmak için ne yaptığımı bilmiyorum.

Bulduğum uzak bağlantıya bağlanmak için bu yararlı ipucunu kullanarak yazılımımın dışındaki bağlantıyı yeniden test ettim.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

kısa bir aramadan sonra bunu Microsoft web sitesinde https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message'da buldu .

aracı SQL sunucusunda çalıştırın, durum hata veriyorsa herhangi bir sorun olup olmadığına bakın ve ardından görünen düzeltme düğmesine basın.

Bu benim için sorunu çözdü.

Bunun nedeni genellikle eksik, yanlış veya yinelenen Hizmet İlkesi Adlarıdır (SPN'ler)

Çözülecek adımlar:

1. SQL Server'ın hangi AD hesabını kullandığını onaylayın
2. Powershell veya CMD'de yönetici modunda aşağıdaki komutu çalıştırın (hizmet hesabı etki alanını içermemelidir)

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

3. Döndürülen çıktının tam nitelikli, tam nitelikli olmayan, bağlantı noktası ve bağlantı noktası olmayan bir SPN içerdiğinden emin olun.

   Beklenen çıktı:

   Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
   MSSQLSvc/<ServerName>.<domain>.com:1433
   MSSQLSvc/<ServerName>:1433                                           
   MSSQLSvc/<ServerName>.<domain>.com
   MSSQLSvc/<ServerName>
   

4. Yukarıdakilerin tümünü görmüyorsanız, yönetici modunda PowerShell veya CMD'de aşağıdaki komutu çalıştırın (varsayılan 1433'ü kullanmıyorsanız bağlantı noktasını değiştirdiğinizden emin olun)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

5. Yukarıdaki tamamlandıktan sonra, DNS yayılımı normalde birkaç dakika sürer

Ayrıca, bulunan yinelenen SPN'ler hakkında bir mesaj alırsanız, bunları silip yeniden oluşturmak isteyebilirsiniz.

Web uygulamasına erişirken bu sorunu yaşadım. Son zamanlarda bir Windows şifresini değiştirmiş olmamdan kaynaklanıyor olabilir.

Web uygulamasını barındırdığım uygulama havuzunun şifresini güncellediğimde bu sorun çözüldü.

İstemci ve sunucu arasındaki saat eşleşmelerini kontrol edin.

Bu hatayı aralıklı olarak aldığımda, yukarıdaki yanıtların hiçbiri işe yaramadı, sonra bazı sunucularımızda zamanın kaymış olduğunu gördük, tekrar senkronize edildikten sonra hata ortadan kalktı. Windows'ta saatin otomatik olarak nasıl eşitleneceğini görmek için w32tm veya NTP'yi arayın.

Kendi sorunuma çözüm ararken buraya geldiğim için, başkalarının da buraya gelmesi durumunda çözümümü burada paylaşacağım.

Makinem başka bir etki alanındaki başka bir ofise taşınana kadar SQL Server'a sorunsuz bağlanıyordum . Ardından, geçişten sonra, hedef asıl adı ile ilgili bu hatayı alıyordum. Sunucu.domain.com gibi tam nitelikli bir ad kullanılarak bağlanılması sorunu giderildi . Ve aslında, ilk sunucuya bu şekilde bağlandıktan sonra, sadece sunucu adını kullanarak (tam yeterlilik olmadan) diğer sunuculara bağlanabilirdim, ancak kilometreniz değişebilir.

Bugün bununla karşılaştım ve düzeltmemi paylaşmak istedim, çünkü bu basitçe gözden kaçıyor ve düzeltmesi kolay.

Kendi rDNS'imizi yönetiyoruz ve yakın zamanda sunucu adlandırma şemamızı yeniden düzenledik. Bunun bir parçası olarak, rDNS'imizi güncellemeliydik ve bunu yapmayı unutmalıyız.

Bir ping doğru ana bilgisayar adını buldu, ancak bir ping -a yanlış ana bilgisayar adını döndürdü.

Kolay düzeltme: rDNS'yi değiştirin, bir ipconfig / flushdns yapın, 30 saniye bekleyin (sadece benim yaptığım bir şey), başka bir ping yapın -a, doğru ana bilgisayar adını çözümlediğini görün, bağlanın ... kar.

Bunun için yeni bir tanesiyle karşılaştım: Sunucu 2012'de barındırılan SQL 2012. SQL AlwaysOn için bir küme oluşturma görevi verildi.
Küme oluşturuldu, herkes SSPI mesajını aldı.

Sorunları çözmek için aşağıdaki komutu çalıştırın:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== SQL için belirlediğim etki alanı hesabı Komutu çalıştırmak için bir Etki Alanı Yöneticisine ihtiyacım vardı. Kümedeki yalnızca bir sunucuda sorunlar vardı.

Ardından SQL yeniden başlatıldı. Şaşırtıcı bir şekilde bağlanabildim.

Bir Visual Studio 2015 Konsol Uygulamasında dizüstü bilgisayarımdan SQL Server 2015 çalıştıran bir VM'ye bağlanmaya çalışıyordum. Uygulamamı bir gece önce çalıştırıyorum ve sorun değil. Sabah uygulamada hata ayıklamaya çalışıyorum ve bu hatayı alıyorum. Denedim ipconfig/flushve release+ renewve bir sürü başka çöp, ama sonunda ...

VM'nizi yeniden başlatın ve istemciyi yeniden başlatın. Bu benim için sorunumu çözdü. Bilmeliydim, her seferinde yeniden başlatma çalışıyor.

Bu sorunu sql sunucumda yaşadım. Spn -D mssqlsvc \ Hostname.domainname Hostname ayarladım sonra durdurdum ve SQL sunucu hizmetimi başlattım.

Sql hizmetimi durdurup başlatmanın bunu yapacağını düşünüyorum.

Aynı sorunu yaşadım, ancak makineyi kilitlemek ve kilidini açmak benim için çalıştı. Bazen güvenlik duvarı sorunları hata verir.

Senin için işe yarayıp yaramayacağından emin değilim, sadece deneyimlerimi paylaşıyorum.

Buradaki tüm çözümleri denedim ve henüz hiçbiri işe yaramadı. Çalışan bir çözüm Bağlan'a tıklamak, sunucu adını girmek, Seçenekler, Bağlantı Özellikleri sekmesini seçmek. "Ağ protokolü" nü "Adlandırılmış Borular" olarak ayarlayın. Bu, kullanıcıların ağ kimlik bilgilerini kullanarak uzaktan bağlanmalarına olanak tanır. Düzeltme aldığımda bir güncelleme göndereceğim.

Benim durumumda, sorun wifi üzerinde DNS kurmaktı. Ayarları kaldırdım, boş bıraktım ve çalıştım.

"Named Pipes" ın "SQL Server Configuration Manager" dan etkinleştirildiğinden emin olun. Bu benim için çalıştı.

1. "SQL Server Yapılandırma Yöneticisi" ni açın.
2. Soldaki listeden "SQL Server Ağ Yapılandırması" nı genişletin.
3. "[Örnek Adınız] için Protokoller" öğesini seçin.
4. Sağdaki listeden "Named Pipes" üzerine sağ tıklayın.
5. "Etkinleştir" i seçin
6. Örnek hizmetinizi yeniden başlatın.

Bu Microsoft Aracı, Magic'e benzer. Çalıştırın, SQL sunucusuna bağlayın ve Düzelt'e tıklayın

Buraya bağlanan eski sürüm SQL server 2017'de çalıştı.

SQL Server için Kerberos Configuration Manager https://www.microsoft.com/en-us/download/details.aspx?id=39046

Benim durumumda, etki alanı olmayan bir ağ üzerindeki bir bilgisayardan başka bir bilgisayardaki SQL Server'a bağlanmak için Integrated Security kullanmaya çalışıyordum . Her iki bilgisayarda da Windows'ta aynı Microsoft hesabıyla oturum açıyordum . Hem PC'lerde yerel bir hesaba geçtim hem de SQL Server şimdi başarıyla bağlanıyor.

Benim durumumda, geliştirme ortamımda çalıştığımdan beri, birisi Etki Alanı Denetleyicisini kapatmıştı ve Windows Kimlik Bilgileri doğrulanamadı. Etki Alanı Denetleyicisini açtıktan sonra, hata ortadan kalktı ve her şey yolunda gitti.

Ağ bağlantılarının neden olduğu bu soruna başka bir niş. Windows VPN istemcisi üzerinden bağlanıyorum ve bu sorun Wifi'den kablolu bir bağlantıya geçtiğimde ortaya çıktı. Durumum için düzeltme, adaptör ölçüsünü manuel olarak ayarlamaktı.

Powershell'de tüm metrik değerleri görmek için Get-NetIPInterface'i kullanın. Daha düşük sayılar daha düşük maliyetlidir ve bu nedenle pencereler tarafından tercih edilirler. Ethernet ve VPN'i değiştirdim ve kimlik bilgileri SSMS'nin mutlu olması için olması gereken yere ulaştı.

Otomatik Metrik özelliğini yapılandırmak için: Denetim Masası'nda Ağ Bağlantıları'na çift tıklayın. Bir ağ arayüzüne sağ tıklayın ve ardından Özellikler öğesini seçin. İnternet Protokolü (TCP / IP) öğesine tıklayın ve ardından Özellikler öğesini seçin. Genel sekmesinde Gelişmiş'i seçin. Bir metrik belirtmek için, IP Ayarları sekmesinde, Otomatik ölçüm onay kutusunu seçip temizleyin ve ardından Arayüz Metriği alanına istediğiniz ölçüyü girin.

Kaynak: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

Bu sorunun bir çeşidiyle karşılaştım, işte özellikler:

• Kullanıcı, adlandırılmış bir örneğe başarılı bir şekilde bağlanabildi , örneğin,Server\Instance başarılı olan
• Kullanıcı oldu yapamaz örneğin bağlantıları için varsayılan örneğine bağlanmak içinServer OP'ın ekran görüntüsü SSPI ilgili başarısız oldu
• Kullanıcı, tam adla varsayılan örneği bağlayamadı; örneğin, Server.domain.com başarısız (zaman aşımı)
• Kullanıcı, adlandırılmış örnek olmadan IP adresine bağlanamadı, örneğin, 192.168.1.134 başarısız
• Etki alanında olmayan diğer kullanıcılar (örneğin, ağa VPN kullanan kullanıcılar) ancak etki alanı kimlik bilgilerini kullanan kullanıcılar, varsayılan örneğe ve IP adresine başarıyla bağlanabildiler

Bu nedenle, bu tek kullanıcının neden bağlanamadığını anlamaya çalışmanın birçok baş ağrısından sonra, durumu düzeltmek için attığımız adımlar şunlardır:

1. SPN listesindeki sunucuya
   setspn -l Server
   bir. Bizim durumumuzda dedi kiServer.domain.com
2. İçinde bulunan hosts dosyasına bir girdi ekleyin C:\Windows\System32\drivers\etc\hosts(bu dosyayı değiştirmek için Yönetici olarak Not Defteri'ni çalıştırın). Eklediğimiz giriş
   Server.domain.com Server

Bundan sonra, SSMS aracılığıyla varsayılan örneğe başarıyla bağlanabildik.

Windows Kimlik Doğrulaması ile oturum açarken SQL Server 2014'te de bu sorunu yaşadım, sorunu çözmek için sunucumu bir kez yeniden başlattım ve sonra oturum açmaya çalıştım, benim için çalıştı.