Ik heb moeite om een SQL Server-verbinding te krijgen van machine A naar machine B waarop de SQL Server draait.
Ik heb uitgebreid gegoogled en alle dingen die ik heb gevonden hebben niet gewerkt. Ze leiden je ook niet stap voor stap door het proces om dit op te lossen.
We gebruiken geen Kerberos, maar NTLM waar geconfigureerd.
De betrokken machines zijn (xx wordt gebruikt om een deel van de machinenaam te verbergen voor veiligheidsdoeleinden):
- xxPRODSVR001– Windows Server 2012-domeincontroller
- xxDEVSVR003– Windows Server 2012 (deze computer genereert de fout)
- xxDEVSVR002– Windows Server 2012 (op deze machine wordt SQL Server 2012 uitgevoerd)
De volgende SPN’s zijn geregistreerd op de DC (xxPRODSVR001). Ik heb het domein verduisterd met yyy om veiligheidsredenen:
Geregistreerde ServicePrincipalNames voor CN=xxDEVSVR002,CN=Computers,DC=yyy,DC=local:
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.localGeregistreerde ServicePrincipalNames voor CN=xxDEVSVR003,CN=Computers,DC=yyy,DC=local:
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
Als het SQL Server-foutbericht nu maar meer beschrijvend was en me vertelde met welke hoofdnaam het probeerde verbinding te maken, zou ik dit misschien kunnen diagnosticeren.
Dus kan iemand me uitleggen hoe ik dit kan oplossen of zie je iets in wat ik heb verstrekt dat verkeerd is?
Ik zou graag meer informatie over debuggen genereren, vertel me wat je nodig hebt.
Antwoord 1, autoriteit 100%
Ik had dit probleem met een ASP.NET MVC-app waar ik aan werkte.
Ik realiseerde me dat ik onlangs mijn wachtwoord had gewijzigd en dat ik het kon herstellen door uit te loggen en weer in te loggen.
Antwoord 2, autoriteit 48%
Ik kreeg deze fout bij het verbinden via SQL Server Management Studio met Windows-verificatie. Mijn wachtwoord was verlopen, maar ik had het nog niet gewijzigd. Eenmaal gewijzigd, moest ik uitloggen en weer inloggen, zodat de machine werkte met mijn nieuwe inloggegevens.
Antwoord 3, autoriteit 33%
Probeer Integrated Security=truein te stellen om deze parameter uit de verbindingsreeks te verwijderen.
BELANGRIJK:Zoals gebruiker @Auspex opmerkte,
Als u Integrated Security verwijdert, wordt deze fout voorkomen, omdat de fout optreedt wanneer u probeert in te loggen met uw Windows-inloggegevens. Helaas wilt u meestal kunnen inloggen met uw Windows-inloggegevens
Antwoord 4, autoriteit 23%
Ik kreeg dezelfde fout bij het proberen via Windows-authenticatie. Klinkt belachelijk, maar voor het geval het iemand anders helpt: het was omdat mijn domeinaccount op de een of andere manier werd vergrendeld terwijl ik nog was ingelogd (!). Het ontgrendelen van het account loste het op.
Antwoord 5, autoriteit 20%
Ik logde in op Windows 10 met een pincode in plaats van een wachtwoord. Ik logde uit en logde weer in met mijn wachtwoord en kon via Management Studio inloggen op SQL Server.
Antwoord 6, autoriteit 20%
De SSPI-contextfout geeft absoluut aan dat authenticatie wordt geprobeerd met behulp van Kerberos.
Aangezien Kerberos-authenticatie Windows-authenticatie van SQL Serverafhankelijk is van Active Directory, wat een versterkte relatie tussen uw computer en uw netwerkdomeincontroller vereist, moet u beginnen met het valideren van die relatie .
Je kunt die relatie snel controleren met het volgende Powershell-commando Test-ComputerSecureChannel.
Test-ComputerSecureChannel -Verbose
Als het Falseretourneert, moet u het beveiligde Active Directory-kanaal van uw computer repareren, aangezien zonder dit geen validatie van domeinreferenties mogelijk is buiten uw computer.
U kunt uw Computer Secure Channel repareren met de volgende Powershell-opdracht:
Test-ComputerSecureChannel -Repair -Verbose
Als het bovenstaande niet werkt (omdat uw domeinreferenties niet werken omdat de machine niet wordt vertrouwd), kunt u in plaats daarvan NETDOM RESETgebruiken vanaf een verhoogde cmd.exe(niet PowerShell) prompt:
NETDOM RESET %COMPUTERNAME% /UserO:domainAdminUserName /Password0:* /SecurePasswordPrompt
(Ja, de opdrachtregelargumenten hebben echt een O(Hoofdletter-“Oh”, niet nul 0). De optie /Password0:* /SecurePasswordPromptgebruikt een pop-up met referenties in plaats van dat u uw wachtwoord rechtstreeks in de opdrachtregel, wat u nooit mag doen).
Controleer de logboeken van beveiligingsgebeurtenissen, als u kerberos gebruikt, zou u aanmeldingspogingen moeten zien met authenticatiepakket: Kerberos.
De NTLM-verificatie mislukt mogelijk en daarom wordt een poging tot Kerberos-verificatie gedaan. Mogelijk ziet u ook een mislukte NTLM-aanmeldingspoging in uw beveiligingsgebeurtenislogboek?
Je kunt kerberos-gebeurtenisregistratie in dev inschakelen om te proberen te achterhalen waarom de kerberos faalt, hoewel het erg uitgebreid is.
Microsoft’s Kerberos Configuration Manager voor SQL Serverkan u helpen dit probleem snel te diagnosticeren en op te lossen.
Hier is een goed verhaal om te lezen: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/
Antwoord 7, autoriteit 15%
Om nog een mogelijke oplossing toe te voegen voor deze meest dubbelzinnige fouten The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):
Controleer of het IP-adres dat wordt opgelost bij het pingen van de SQL Server hetzelfde is als dat in Configuration Manager. Om dit te controleren, opent u SQL Server Configuration Manager en gaat u naar SQL Server Network Configuration > Protocollen voor MSSQLServer > TCP/IP.
Zorg ervoor dat TCP/IP is ingeschakeld en zorg ervoor dat op het tabblad IP-adressen het IP-adres waarnaar de server wordt omgezet bij het pingen, hier hetzelfde is. Dat loste deze fout voor mij op.
Antwoord 8, autoriteit 11%
Het probleem lijkt een probleem met de inloggegevens van Windows te zijn. Ik kreeg dezelfde fout op mijn werklaptop met een VPN. Ik ben zogenaamd ingelogd als mijn domein/gebruikersnaam, wat ik met succes gebruik wanneer ik rechtstreeks verbinding maak, maar zodra ik naar een VPN met een andere verbinding ga, krijg ik deze foutmelding. Ik dacht dat het een DNS-probleem was omdat ik de server kon pingen, maar het bleek dat ik SMSS expliciet moest uitvoeren als mijn gebruiker vanaf de opdrachtprompt.
bijv
runas /netonly /user:YourDoman\YourUsername “C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe”
Antwoord 9, autoriteit 8%
Log in op zowel uw SQL Box als uw client en typ:
ipconfig /flushdns
nbtstat -R
Als dat niet werkt, vernieuw dan je DHCP op je clientcomputer… Dit werkt voor 2 pc’s in ons kantoor.
Antwoord 10, autoriteit 6%
Ik kwam dit net tegen en heb het opgelost door twee dingen te doen:
- Lees-/schrijfmachtigingen voor servicePrincipalName toekennen aan het serviceaccount met behulp van ADSI Edit, zoals beschreven in https ://support.microsoft.com/en-us/kb/811889
-
De SPN’s verwijderen die eerder bestonden op het SQL Server computeraccount(in tegenstelling tot het serviceaccount) met
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAMEwaarbij 1234het poortnummer was dat door de instantie werd gebruikt (de mijne was geen standaardinstantie).
Antwoord 11, autoriteit 6%
Controleer of uw klok overeenkomt tussen de client en de server.
Toen ik deze fout af en toe kreeg, werkte geen van de bovenstaande antwoorden. Toen ontdekten we dat de tijd op sommige van onze servers was verstreken. Toen ze opnieuw waren gesynchroniseerd, verdween de fout. Zoek naar w32tm of NTP om te zien hoe u de tijd automatisch kunt synchroniseren in Windows.
Antwoord 12, autoriteit 6%
In mijn geval loste het herstarten van SQL Server 2014 (op mijn ontwikkelserver) het probleem op.
Antwoord 13, autoriteit 6%
Ik was IPv6 aan het testen op een cluster van pc’s in een geïsoleerd netwerk en kwam dit probleem tegen toen ik terugging naar IPv4. Ik was aan het spelen in de actieve map, DNS en DHCP, dus ik heb geen idee wat ik heb geprikt om de Kerberos-setup te verbreken.
Ik heb de verbinding buiten mijn software opnieuw getest met deze handige tip om verbinding op afstand te maken die ik heb gevonden.
https:// blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/
vervolgens na een korte zoektocht dit gevonden op de Microsoft-website
https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message.
voer de tool uit op de SQL-server en kijk of er een probleem is
als de status een fout aangeeft, druk dan op de herstelknop die verschijnt.
Dit heeft het probleem voor mij opgelost.
Antwoord 14, autoriteit 5%
Ik had dit probleem bij het openen van de webtoepassing. Het kan zijn dat ik onlangs een Windows-wachtwoord heb gewijzigd.
Dit probleem is opgelost toen ik het wachtwoord heb bijgewerkt voor de app-pool waar ik de webtoepassing heb gehost.
Antwoord 15, autoriteit 3%
Deze Microsoft Tool is als Magic. Voer het uit, verbind het met de SQL-server en klik op Repareren
De oude versie die hier is gelinkt, werkte op SQL server 2017.
Kerberos Configuration Manager voor SQL Server
https://www.microsoft.com/en-us/ download/details.aspx?id=39046
Antwoord 16, autoriteit 3%
In mijn situatie probeerde ik Integrated Security te gebruiken om vanaf een pc verbinding te maken met SQL Server op een andere pc op een netwerk zondereen domein. Op beide pc’s was ik aanmelden bij Windows met hetzelfde Microsoft-account. Ik schakelde over naar een lokaal accountop beide pc’s en SQL Server maakt nu succesvol verbinding.
Antwoord 17, autoriteit 3%
Voor het geval iemand het zich afvraagt, ik heb de MS-terminologie ontward:
Target = (active directory) target
Active directory target = target server running the domain controller
Domain controller = server that verifies your login information
Principal name = your windows username
SSPI = security support provider interface
Security support provider interface = software interface that manages "authenticated
communications" and allows SSPs like TLS to allow SSL, among others
SSP = security support provider (SSPI implementation)
TLS/SSL = you should already know this
= Kan uw wachtwoord niet verifiëren.
Antwoord 18, autoriteit 2%
Aangezien ik hier belandde toen ik op zoek was naar een oplossing voor mijn eigen probleem, zal ik mijn oplossing hier delen, voor het geval anderen hier ook terechtkomen.
Ik maakte een goede verbinding met SQL Server totdat mijn machine werd verplaatst naar een ander kantoor op een ander domein. Toen, na de overstap, kreeg ik deze fout met betrekking tot de naam van de doelprincipal. Wat het probleem oploste, was verbinding maken met een volledig gekwalificeerde naamzoals: server.domain.com. En eigenlijk, toen ik op die manier verbinding had gemaakt met de eerste server, kon ik verbinding maken met andere servers met alleen de servernaam (zonder de volledige kwalificatie), maar je aantal kilometers kan variëren.
Antwoord 19, autoriteit 2%
Ik kwam dit vandaag tegen en wilde mijn oplossing delen, aangezien deze eenvoudig over het hoofd wordt gezien en gemakkelijk te repareren is.
We beheren onze eigen rDNS en hebben onlangs ons servernaamgevingsschema aangepast. Als onderdeel daarvan hadden we onze rDNS moeten updaten en vergeten dit te doen.
Een ping leverde de juiste hostnaam op, maar een ping -a leverde de verkeerde hostnaam op.
Eenvoudige oplossing: verander de rDNS, doe een ipconfig /flushdns, wacht 30 seconden (gewoon iets wat ik doe), doe nog een ping -a , kijk of het de juiste hostnaam oplost, maak verbinding … winst.
Antwoord 20, autoriteit 2%
Ik kwam hiervoor een nieuwe tegen: SQL 2012 gehost op Server 2012.
Kreeg de taak om een cluster te maken voor SQL AlwaysOn.
Cluster is gemaakt, iedereen heeft het SSPI-bericht ontvangen.
Om de problemen op te lossen, werd het volgende commando uitgevoerd:
setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService
DomainNamerunningSQLService== het domeinaccount dat ik heb ingesteld voor SQL
Ik had een domeinbeheerder nodig om de opdracht uit te voeren. Slechts één server in het cluster had problemen.
Vervolgens SQL opnieuw gestart. Tot mijn verbazing kon ik verbinding maken.
Antwoord 21, autoriteit 2%
Ik probeerde verbinding te maken met een virtuele machine met SQL Server 2015 vanaf mijn laptop in een Visual Studio 2015 Console-app. Ik draai mijn app de avond ervoor en het is prima. ‘S Morgens probeer ik de app te debuggen en krijg ik deze foutmelding. Ik heb ipconfig/flushen release+ renewen een heleboel andere rotzooi geprobeerd, maar uiteindelijk…
Start uw VM opnieuw op en start de client opnieuw. Dat loste het voor mij op. Ik had het kunnen weten, herstart werkt elke keer.
Antwoord 22, autoriteit 2%
Ik had dit probleem op mijn sql-server. Ik setspn -D mssqlsvc\Hostname.domainname Hostname stopte toen en startte mijn SQL-serverservice.
Ik denk dat het voldoende zou zijn geweest om mijn sql-service te stoppen en te starten.
Antwoord 23, autoriteit 2%
Ik had hetzelfde probleem, maar het vergrendelen en ontgrendelen van de machine werkte voor mij. Soms geven firewallproblemen fouten.
Ik weet niet zeker of het voor jou zal werken of niet, ik deel alleen mijn ervaring.
Antwoord 24, autoriteit 2%
Ik heb alle oplossingen hier geprobeerd en geen enkele heeft tot nu toe gewerkt. Een tijdelijke oplossing die werkt, is door op Verbindente klikken, de servernaam in te voeren, Opties, tabblad Verbindingseigenschappen te selecteren. Stel het “Netwerkprotocol” in op “Named Pipes”. Hierdoor kunnen gebruikers op afstand verbinding maken met hun netwerkreferenties. Ik zal een update plaatsen als ik een oplossing heb.
Antwoord 25, autoriteit 2%
In mijn geval was het probleem het instellen van DNS op de wifi. Ik heb de instellingen verwijderd en leeg gelaten, en werkte.
Antwoord 26, autoriteit 2%
Zorg ervoor dat “Named Pipes” zijn ingeschakeld vanuit “SQL Server Configuration Manager”. Dit werkte voor mij.
- Open “SQL Server Configuration Manager”.
- Breid “SQL Server-netwerkconfiguratie” uit in de lijst aan de linkerkant.
- Selecteer “Protocollen voor [uw instantienaam]”.
- Klik met de rechtermuisknop op “Named Pipes” in de lijst aan de rechterkant.
- Selecteer “Inschakelen”
- Start uw instantieservice opnieuw.
Antwoord 27, autoriteit 2%
In mijn geval, aangezien ik in mijn ontwikkelomgeving werkte, had iemand de domeincontroller afgesloten en konden Windows-referenties niet worden geverifieerd. Na het inschakelen van de domeincontroller verdween de fout en werkte alles prima.
Antwoord 28, autoriteit 2%
Nog een niche voor dit probleem, veroorzaakt door netwerkverbindingen. Ik maak verbinding via Windows VPN-client en dit probleem deed zich voor toen ik overschakelde van wifi naar een bekabelde verbinding. De oplossing voor mijn situatie was om de adapterstatistieken handmatig aan te passen.
Gebruik in powershell Get-NetIPInterface om alle metrische waarden te zien. De lagere nummers zijn goedkoper en daarom hebben ze de voorkeur van Windows. Ik wisselde van ethernet en VPN en de inloggegevens kwamen waar ze moesten zijn om SSMS gelukkig te maken.
De functie Automatische metrische gegevens configureren:
Dubbelklik in het Configuratiescherm op Netwerkverbindingen.
Klik met de rechtermuisknop op een netwerkinterface en selecteer vervolgens Eigenschappen.
Klik op Internet Protocol (TCP/IP) en selecteer vervolgens Eigenschappen.
Selecteer op het tabblad Algemeen de optie Geavanceerd.
Als u een metriek wilt opgeven, schakelt u op het tabblad IP-instellingen het selectievakje Automatische metriek uit en voert u vervolgens de gewenste metriek in het veld Interfacemetriek in.
Antwoord 29
Ik kwam een variant van dit probleem tegen, dit waren de kenmerken:
- Gebruiker kon met succes verbinding makenmet een benoemde instantie, verbindingen met
Server\Instancewaren bijvoorbeeld succesvol - Gebruiker was niet in staatom verbinding te maken met de standaardinstantie, bijvoorbeeld, verbindingen met
Servermislukten met de OP’s screenshot met betrekking tot SSPI - Gebruiker kon standaardinstantie niet verbinden met volledig gekwalificeerde naam, bijvoorbeeld verbindingen met
Server.domain.commislukt (time-out) - Gebruiker kon geen IP-adres verbinden zonder genoemde instantie, bijvoorbeeld verbindingen met
192.168.1.134mislukt - Andere gebruikers die zich niet in het domein bevinden (bijvoorbeeld gebruikers die VPN op het netwerk hebben) maar die domeinreferenties gebruikten, konden verbinding maken met de standaardinstantie en het IP-adres
Dus na veel hoofdpijn om erachter te komen waarom deze enkele gebruiker geen verbinding kon maken, volgen hier de stappen die we hebben genomen om de situatie op te lossen:
- Bekijk de server in de SPN-lijst met
setspn -l Server
A. In ons geval stond erServer.domain.com - Voeg een vermelding toe aan het hosts-bestand in
C:\Windows\System32\drivers\etc\hosts(voer Kladblok uit als beheerder om dit bestand te wijzigen). Het item dat we hebben toegevoegd was
Server.domain.com Server
Hierna konden we met succes verbinding maken via SSMS met de standaardinstantie.