Momentan sunteți offline, așteptați să vă reconectați la internet

Cum se depanează mesajul de eroare "Nu pot genera SSPI contextul"

Asistența pentru Windows Server 2003 s-a încheiat la 14 iulie 2015

Microsoft a încheiat asistența pentru Windows Server 2003 14 iulie 2015. Această schimbare a afectat actualizările de software și opțiunile de securitate. Aflați ce înseamnă aceasta pentru dvs. și cum puteți rămâne protejat.

IMPORTANT: Acest articol a fost tradus de software-ul de traducere automată Microsoft, si nu de un traducător. Microsoft vă oferă atât articole traduse de persoane, cât şi articole traduse automat, astfel incat aveti access la toate articolele din Baza noastră de informatii în limba dvs. materna. Totuşi, un articol tradus automat nu este întotdeauna perfect. Acesta poate conţine greşeli de vocabular, sintaxă sau gramatică, la fel cum un vorbitor străin poate face greşeli vorbind limba dvs. materna. Compania Microsoft nu este responsabilă pentru nici o inexactitate, eroare sau daună cauzată de traducerea necorespunzătoare a conţinutului sau de utilizarea traducerii necorespunzătoare de către clienţii nostri. De asemenea, Microsoft actualizează frecvent software-ul de traducere automată.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 811889
Dacă sunteţi un client de afaceri mici, găsi suplimentare de depanare şi de învăţare resurse la Suport pentru afaceri mici site-ul.

Înţelegerea problemei

Această secţiune vă oferă informaţii de fond de ce apare mesajul de eroare "Nu pot genera SSPI contextul" şi cum se depanează eroarea. Este posibil să primiţi acest mesaj de eroare dacă următoarele condiţii sunt adevărate:
  • Vă conectați la Microsoft SQL Server.
  • Utilizaţi integrate de securitate.
  • Autentificarea Kerberos este utilizat pentru a efectua Delegaţia de securitate.
Înţelegerea terminologiei Kerberos şi nume principal serviciu
Driverul de SQL Server pe un computer client utilizează securitate integrată a utiliza simbolul de securitate Windows contului de utilizator să se conecteze cu succes la un computer care execută SQL Server. Simbolul de securitate Windows este delegată la client la computer care execută SQL Server. Driverul de SQL Server efectuează această delegaţie atunci când simbol de securitate al utilizatorului este delegată la un calculator la altul utilizând unul dintre următoarele configuraţii:
  • NTLM prin canale declarate (nu utilizaţi securitate suport furnizor interfata [SSPI])
  • NTLM prin TCP/IP prize cu SSPI
  • Autentificarea Kerberos prin TCP/IP prize cu SSPI
Securitatea suport furnizor de interfaţă (SSPI) este un set de API-uri Windows, care permite pentru autentificare de delegare şi reciproc peste orice strat de transportul acoperire de date generice, precum TCP/IP prize. Prin urmare, SSPI permite pentru un computer pe care rulează un sistem de operare Windows pentru în siguranţă delega un token de securitate de utilizator la un computer la altul peste orice stratul de transport, care pot transmite prime bytes acoperire de date.

Eroarea "Nu poate genera SSPI contextul" este generat atunci când SSPI utilizează autentificarea Kerberos delega prin TCP/IP şi autentificarea Kerberos nu poate finaliza operațiunilor necesare pentru a delega cu succes simbol de securitate de utilizator la destinatie computer care execută SQL Server.
De ce interfaţă de furnizor de securitate suport utilizează autentificarea NTLM sau Kerberos
Autentificarea Kerberos foloseste un identificator numit "Serviciu Principal nume" (SPN). Ia în considerare o SPN ca un identificator unic domeniu sau pădure, unele instanţe într-un server de resurse. Puteţi avea un SPN pentru un serviciu web, pentru un serviciu de SQL sau pentru un serviciu SMTP. Aveţi mai multe instanţe de consolidare servicii web pe acelaşi computer fizic care are un unic SPN.

O SPN pentru SQL Server este compus din următoarele elemente:
  • ServiceClass: aceasta identifică clasa generale de serviciu. Acest lucru este întotdeauna MSSQLSvc pentru SQL Server.
  • Gazdă: acesta este un domeniu complet calificat nume de sign-in DNS a calculatorului pe care se execută SQL Server.
  • Port: acesta este numărul de port care serviciul este de ascultare pe.
De exemplu, un tipic SPN pentru un computer care execută SQL Server este după cum urmează:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Formatul de un SPN pentru o instanţă implicită şi formatul de un SPN pentru instanţă denumită nu sunt diferite. Numărul portului este ceea ce legături SPN pentru o instanţă.

Când conducătorul de SQL Server pe un client foloseste securitate integrată pentru conectarea la SQL Server, codul de şofer pe client încearcă să rezolve DNS complet calificat de computer care execută SQL Serverul utilizând WinSock API-uri de reţea. Pentru a efectua această operaţiune, codul de conducător auto solicită gethostbyname şi gethostbyaddr WinSock APIs. Chiar dacă un IP adresă sau gazdă nume este trecut ca nume de sign-in de computer care execută SQL Server, SQL Server conducătorului auto încearcă să rezolva DNS complet calificat a computerului în cazul în care computerul este folosind integrate de securitate.

Atunci când conducătorul auto SQL Server pe client se rezolvă DNS complet calificat de computer care execută SQL Server, DNS corespunzătoare este folosit pentru a forma SPN pentru acest computer. Prin urmare, orice probleme despre modul în care IP adresă sau gazdă nume este rezolvată la DNS complet calificat de WinSock poate provoca driverul de SQL Server pentru a crea un SPN nevalidă pentru computer care execută SQL Server.

De exemplu, SPNs incorect că driverul de SQL Server client-parte pot forma ca rezolvat DNS complet calificat sunt după cum urmează:
  • MSSQLSvc / SQLSERVER1:1433
  • MSSQLSvc/123.123.123.123:1433
  • MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
  • MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
Atunci când conducătorul auto SQL Server formează o SPN care nu este valid, autentificare funcţionează încă pentru că interfaţa SSPI încearcă să caute SPN din serviciul director Active Directory, şi nu găseşte SPN. Dacă interfaţa SSPI nu găsi SPN, autentificarea Kerberos nu se efectuează. În acel moment, stratul de SSPI comută la un mod de autentificare NTLM şi conecta utilizează autentificarea NTLM şi obicei reuşeşte. În cazul în care conducătorul auto SQL Server formează o SPN că este validă, dar nu este atribuită recipient adecvat, ea încearcă să folosească SPN dar nu pot. Acest lucru provoacă un mesaj de eroare "Nu pot genera SSPI contextul". Dacă SQL Server de pornire contul este un cont de sistem local, recipient adecvat este nume de sign-in computerului. Pentru orice alt cont, recipient adecvat este contul de pornire SQL Server. Pentru autentificare va încerca să utilizeze SPN prima pe care le găseşte, asiguraţi-vă că nu există nici o SPNs atribuite incorect containere. Cu alte cuvinte, fiecare SPN trebuie atribuite pe unul şi numai un singur container.

Factorul cheie care face autentificarea Kerberos succes este validă DNS funcţionalitatea pe reţea. Puteţi verifica această funcţionalitate pe client şi server utilizând utilitarul de comandă Ping. Pe computer client, executaţi următoarea comandă pentru a obţine Adresă IP a serverului care execută SQL Server (în cazul în care nume de sign-in de computer care execută SQL Server este SQLServer1):
ping sqlserver1
Pentru a vedea dacă utilitarul Ping rezolvă DNS complet calificat SQLServer1, executaţi următoarea comandă:
ping - un IPAddress
De exemplu:
C:\>ping SQLSERVER1Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:	Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128	Ping statistics for 123.123.123.123:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 0ms, Maximum =  0ms, Average =  0ms
C:\>ping -a 123.123.123.123	Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:	Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Ping statistics for 123.123.123.123:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 0ms, Maximum =  0ms, Average =  0msC:\>
Atunci când comanda ping - un IPAddress rezolvă pentru DNS complet calificat corectă a computerului care execută SQL Server, rezoluţie de partea de client este de asemenea succes.
Crearea de SQL Server nume principal serviciu
Aceasta este una dintre părţile importante ale autentificarea Kerberos şi SQL Server interacţiune. Cu SQL Server, aveţi posibilitatea să executaţi serviciul SQL Server sub una dintre următoarele: o contul LocalSystem, un cont de utilizator local sau un cont de utilizator de domeniu. La pornirea în instanţă de SQL Server de serviciu, încearcă să vă înregistraţi propria sa SPN în Active Directory utilizând apelul DsWriteAccountSpn API. În cazul în care apelul nu este de succes, următorul avertisment este înregistrate în vizualizatorul de evenimente:

Sursa: MSSQLServer EventID: 19011 Descriere: SuperSocket info: (SpnRegister): eroare 8344.

Pentru mai multe informaţii despre funcţia de DsWriteAccountSpn , du-te la următorul site Web Microsoft:
Explicaţie simplificată
Dacă executaţi serviciul SQL Server în contul LocalSystem, SPN este inscris automat şi autentificarea Kerberos interactioneaza cu succes de la un computer care execută SQL Server. Cu toate acestea, dacă executaţi serviciul SQL Server sub un cont de domeniu sau sub un cont local, încercarea de a crea SPN va eşua în cele mai multe cazuri pentru un cont de domeniu şi contul locale nu au dreptul de a stabili propriile SPNs. Atunci când crearea SPN nu este de succes, acest lucru înseamnă că nici o SPN este configurat pentru computer care execută SQL Server. În cazul în care vă testa folosind un cont de administrator domeniu ca și contul serviciu de SQL Server, SPN este creat cu succes deoarece acreditările de nivel de administrator domeniu că trebuie să aveţi pentru a crea un SPN sunt prezente.

Deoarece nu s-ar putea folosi un cont de administrator domeniu pentru a rula serviciul SQL Server (pentru a preveni riscul de securitate), computer care execută SQL Server nu poate crea propria sa SPN. Prin urmare, trebuie să creaţi manual un SPN pentru computer care execută SQL Server dacă doriţi să utilizaţi autentificarea Kerberos, când vă conectaţi la un computer care execută SQL Server. Acest lucru este adevărat dacă executaţi SQL Server, în temeiul unui cont de utilizator de domeniu sau un cont de utilizator local. SPN creaţi trebuie atribuite la contul de serviciu de serviciul SQL Server pe acel computer special. SPN nu poate atribuite recipientul de computerul cu excepţia cazului în computer care execută SQL Server începe cu contul local sistem. Trebuie să existe un singur şi singur SPN, şi trebuie să fie atribuite recipient adecvat. De obicei, acesta este contul curent de serviciul SQL Server, dar aceasta este containerul de cont calculator cu contul local sistem.

Rezolvarea problemei

Această secţiune afişează paşii pentru a vă asigura că computerul nu experienţă probleme SSPI.

Verifica domeniu
Verificaţi că domeniul la care vă conectaţi poate comunica cu domeniu care aparține computer care execută SQL Server. Acolo trebuie să fie, de asemenea, nume de sign-in corect rezoluţie în domeniu.
  1. Trebuie să vă asiguraţi că vă poate cu succes conecta la Windows utilizând acelaşi domeniu de cont şi parola ca și contul de pornire a serviciului de SQL Server. De exemplu, SSPI eroare poate să apară în una din următoarele situaţii:
    • Cont de domeniu este blocat.
    • S-a schimbat parola contului. Cu toate acestea, niciodată nu reporniţi serviciul SQL Server dupa ce s-a schimbat parola.
  2. Dacă vă domeniu de conecta diferă de domenii de computer care execută SQL Server, verificaţi relaţie de încredere între domenii.
  3. Verificaţi dacă domeniul pe care server aparţine şi de cont de domeniu pe care le utilizaţi pentru a conecta în aceeaşi pădure. Acest lucru este necesar pentru SSPI la locul de muncă.
  4. Utilizarea Cont este de încredere pentru delegarea opţiunea în Active Directory Users and Computers atunci când veţi începe SQL Server.

    Notă "Cont este de încredere pentru delegaţia" chiar este necesar numai când sunt delegarea acreditările la ţintă SQL server la un SQL server de la distanţă cum ar fi un scenariu de hamei dublu ca distribuite interogări (interogări de server legat), care utilizează autentificare Windows.
  5. Folosesc manipula nume principal serviciu pentru conturi (SetSPN.exe) de utilitate în Windows 2000 Resource Kit. Conturile de administrator domeniu Windows 2000 sau Windows Server 2003 conturile de administrator domeniu pot folosi utilitarul pentru a controla SPN care este atribuit un serviciu şi un cont. Pentru SQL Server, trebuie să existe un singur şi singur SPN. SPN trebuie să atribuie container corespunzător, contul curent de serviciul SQL Server în cele mai multe cazuri şi cont pentru computer când SQL Server începe cu contul sistemul local. Dacă începeţi SQL Server conectat contul LocalSystem, SPN este automat configurat. Cu toate acestea, dacă utilizaţi un cont de domeniu pentru a lansarea SQL Server, sau atunci când vă schimbaţi contul utilizat pentru lansarea SQL Server, trebuie să executaţi SetSPN.exe pentru a elimina expirat SPNs, şi apoi trebuie să adăugaţi un SPN valabil. Pentru mai multe informații, consultați subiectul "Securitate cont Delegaţia" în SQL Server 2000 carti Online. Pentru a face acest lucru, du-te la următorul site Web Microsoft:Pentru mai multe informaţii despre Windows 2000 Resource Kit-uri, du-te la următorul site Web Microsoft:
  6. Verificaţi că nume de sign-in rezoluţie este apar corect. Nume de rezoluţie metode pot include DNS, câştigă, fisierele de host-uri şi fişiere Lmhosts. Pentru mai multe informaţii despre problemele de rezoluţie nume de sign-in şi depanare, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
    169790Cum se depanează bază TCP/IP probleme
  7. Pentru mai multe informaţii despre cum se depanează problemele de accesibilitate şi firewall-ul probleme cu Active Directory, faceţi clic pe următoarele numere de articol pentru a vedea articolele în bază de cunoştinţe Microsoft:
    291382întrebări frecvente despre Windows 2000 DNS şi Windows Server 2003 DNS
    224196 Restrictionarea traficului de replicare Active Directory şi trafic RPC clientului la un anumit port
Configuraţi serviciul SQL Server pentru a crea SPNs dinamic pentru cazuri de SQL Server
Pentru a configura serviciul SQL Server pentru a crea SPNs dinamic, trebuie să modificaţi setările de control acces cont din serviciul director Active Directory. Trebuie să Acordaţi permisiuni "Citire NumePrincipalServiciu" şi "Scrie NumePrincipalServiciu" permisiunea pentru contul de serviciu a SQL Server.

Avertizare Dacă utilizaţi de completare snap-in Active Director Serviciul interfeţe (ADSI) Edit, utilitarul LDP sau orice alte LDAP versiunea 3 clienţi şi modificaţi incorect atributele obiectelor Active Directory, pot cauza probleme grave. Aceste probleme pot necesita reinstalarea Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, sau atât Windows şi schimb. Nu putem garanta că problemele cauzate de schimbarea incorect atributele obiectelor Active Directory poate fi rezolvată. Schimba aceste atribute la propriul risc.

Notă Pentru a acorda permisiuni corespunzătoare şi drepturi utilizator în contul de pornire de SQL Server, trebuie să fie conectat ca un administrator domeniu, trebuie să întrebaţi administratorul de domeniu pentru această activitate.

Pentru a configura serviciul SQL Server pentru a crea dinamic SPNs, urmaţi aceşti paşi:
  1. Faceţi clic pe Începe, faceţi clic pe A alerga, tip Adsiedit.msc, apoi faceţi clic pe ok.
  2. În ADSI Edit completare snap-in, extinde Domeniu [Domeniului], extinde DC = RootDomainName, extinde NC = utilizatori, faceţi clic dreapta pe NC = AccountName, apoi faceţi clic pe Proprietăţi.

    Note
    • Domeniului este un substituent pentru nume de sign-in de domeniu.
    • RootDomainName este un substituent pentru nume de sign-in de domenii rădăcină.
    • AccountName este un substituent pentru contul pe care îl specificaţi pentru a porni serviciul SQL Server.
    • Dacă specificaţi cont Local System pentru a porni serviciul SQL Server, AccountName este un substituent pentru contul pe care le utilizaţi să faceţi conecta Microsoft Windows.
    • Dacă specificaţi un cont de utilizator de domeniu pentru a porni serviciul SQL Server, AccountName este un substituent pentru acest cont de utilizator de domeniu.
  3. În NC = AccountName Proprietăţi casetă de dialog, faceţi clic pe Securitate fila.
  4. Pe Securitate tab-ul, faceţi clic pe Avansate.
  5. În Setări de securitate avansate casetă de dialog, asiguraţi-vă că AUTO este listat sub Intrările de permisiune.

    Dacă AUTO este nu este listat, faceţi clic pe Adauga, şi apoi adăugaţi AUTO.
  6. Sub Intrările de permisiune, faceţi clic pe AUTO, apoi faceţi clic pe Editare.
  7. În Permisiunea de intrare casetă de dialog, faceţi clic pe Proprietăţi fila.
  8. Pe Proprietăţi tab-ul, faceţi clic pe Acest obiect numai în Se aplică pe listă, şi apoi asiguraţi-vă că casetele de selectare pentru următoarele permisiuni sunt selectate în conformitate cu Permisiuni:
    • Citiţi NumePrincipalServiciu
    • Scrie NumePrincipalServiciu
  9. Faceţi clic pe ok de trei ori, şi apoi ieşire ADSI Edit completare snap-in.
Pentru a vă ajuta cu acest proces, contactaţi asistenţa pentru produse Active Directory, şi menţionează acest articol din bază de cunoştinţe Microsoft.

Importante Vă recomandăm că vă acordă WriteServicePrincipalName dreptul la contul de serviciu SQL atunci când următoarele condiţii sunt adevărate:
  • Există mai multe controlere de domeniu.
  • SQL Server este grupată.
În acest scenariu, SPN pentru SQL Server poate fi şters din cauza latență la reproducere Active Directory. Acest lucru poate provoca probleme de conectivitate la instanţă de SQL Server.

Presupune că aveţi următoarele:
  • O instanţă de SQL virtuale numit Sqlcluster cu două noduri: nod A şi B. de nod
  • Nod A este autentificat de controler de domeniu A şi B de nod este autentificat de controler de domeniu B.


Următoarele pot apărea:
  1. Exemplu Sqlcluster este activă pe nod A şi înregistrate SQL SPN în controlerul de domeniu A în timpul începe până...
  2. Instanta Sqlcluster nu peste nodul B atunci când nodul A este de închidere în mod normal.
  3. Instanta Sqlcluster retras sa SPN la controlerul de domeniu A în timpul procesului de închidere pe nod A.
  4. SPN este eliminat din controlerul de domeniu A, dar schimbarea nu a mai fost replicat la controlerul de domeniu B.
  5. Pornirea pe nodul B instanţă Sqlcluster încearcă să se înregistreze SQL SPN cu controler de domeniu B. De atunci, SPN există încă nodul B nu se inregistreaza SPN.
  6. După ceva marcă de timp, controler de domeniu A reproduce ştergerea SPN (de la Pasul 3) la controlerul de domeniu B ca parte a reproducerii Active Directory. Rezultatul final este că nici SPN valabil există pentru instanţă de SQL în domeniu şi, prin urmare, veţi vedea probleme de conectare la instanţă de Sqlcluster.

Notă Acest număr este fixat în SQL Server 2012.
Verifica server mediu
Verifica unele setări de bază pe computerul unde este SQL Server instalat:
  1. Autentificarea Kerberos nu este acceptat pe computere bazate pe Windows 2000 care se execută Windows Clustering excepţia cazului în care le-aţi aplicat pachet Service Pack 3 (sau o versiune ulterioară) pentru Windows 2000. Prin urmare, orice încercare de a utiliza autentificare SSPI pe un cluster instanţă de SQL Server ar putea eşua. Pentru mai multe informaţii, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
    235529Suport de autentificare Kerberos pe clustere bazate pe Windows 2000 server
  2. Verificaţi că serverul execută Windows 2000 pachet Service Pack 1 (SP1). Pentru mai multe informaţii despre suportul de autentificare Kerberos pe serverele bazate pe Windows 2000, faceţi clic pe următorul număr de articol pentru a vedea articolul în Microsoft Knowledge Bază de:
    267588Mesaj de eroare "Nu pot genera SSPI contextul" este afişat atunci când vă conectaţi la SQL Server 2000
  3. Într-un cluster, în cazul în care contul pe care le utilizaţi pentru a începe SQL Server, SQL Server Agent sau text complet Căutaţi serviciilor modificărilor, cum ar fi o parolă nouă, urmaţi paşii care sunt furnizate în următorul articol din bază de cunoştinţe Microsoft:
    239885 Cum de a schimba conturile de serviciu pentru un computer cluster care execută SQL Server
  4. Să verifice dacă contul pe care le utilizaţi pentru a începe SQL Server permisiunile corespunzătoare. Dacă utilizaţi un cont care nu este membru al grupului Local administratori, consultaţi "Setarea sus Ferestre consolidare servicii conturi" subiect în SQL Server Books Online pentru o listă detaliată a permisiunilor că acest cont trebuie să aibă:
Verificaţi mediul clientului
Verificaţi următoarele pe client:
  1. Asiguraţi-vă că furnizorul de asistenţă de securitate NTLM este instalat corect şi activat pe client. Pentru mai multe informaţii, faceţi clic pe următorul număr de articol pentru a vedea articolul în Microsoft Knowledge Bază de:
    269541Mesaj de eroare la conectarea la SQL Server dacă cheie de registry Windows NT LM suport furnizor de securitate lipseşte: "nu pot genera SSPI contextul"
  2. Determina dacă utilizaţi acreditări de cache. Dacă sunteţi conectat la client utilizând acreditările de cache, Log off de pe computer şi apoi log pe spate, atunci când vă puteţi conecta la un controler de domeniu pentru a preveni cache acreditările de utilizat. Pentru mai multe informaţii despre cum să determina dacă utilizaţi acreditări stocate în cache, faceţi clic pe următorul articol număr pentru a vedea articolul în bază de cunoştinţe Microsoft:
    242536Utilizatorul nu este avertizat când logare pe cu domeniu cache acreditări
  3. Verificaţi că datele pe server şi client sunt valabile. În cazul în care datele sunt prea departe una de cealaltă, certificatele pot fi considerate invalide.
  4. SSPI utilizează un fişier denumit Security.dll. În cazul în care orice altă aplicaţie, se instalează un fişier care utilizează acest nume, se pot utiliza alte fişierul cu fişierul SSPI. Pentru mai multe informaţii, faceţi clic pe următorul număr de articol pentru a vedea articolul în Microsoft Baza de cunoştinţe:
    253577Eroare: 80004005 - driverul ODBC MS SQL Server nu poate iniţializa SSPI pachet
  5. Dacă sistemul de operare pe client este Microsoft Windows 98, trebuie să instalaţi clientul pentru Microsoft Networks componentă pe client. Pentru mai multe informaţii, faceţi clic pe următorul număr de articol pentru a vedea articolul în Microsoft Knowledge Bază de:
    267550BUG: "eşec afirmaţie" atunci când vă conectaţi la un Server SQL prin TCP/IP
Verificaţi dacă utilitarul reţea client de
Utilitate Client de reţea (badea) este livrat cu Microsoft Data Access Components (MDAC) şi este utilizat pentru a configura connectivity la spre computere care execută SQL Server. Utilizaţi utilitarul MDAC Cliconfg.exe NONO pentru a configura connectivity:
  1. Pe Generale fila, protocoale de cale sunt definit variază în funcţie de versiunea de MDAC. Cu versiuni anterioare ale MDAC, aveţi posibilitatea să selectaţi un protocol "implicit". Pe cele mai recente versiuni de MDAC, puteţi permite una sau mai multe protocoale cu unul la partea de sus a Listă tabel atunci când vă conectaţi SQL Server. Deoarece SSPI se aplică numai TCP/IP, aveţi posibilitatea să utilizaţi un alt Protocolul, precum tevi numit, pentru a evita eroarea.
  2. Verifica Pseudonim fila în badea să verifice că un alias este definită pentru serverul pe care încercaţi să vă conectaţi. Dacă este definit un alias de serverul, verificaţi setările pentru cum acest computer este configurat pentru a vă conecta la serverul SQL. Puteţi verifica acest lucru prin ştergerea aliasul server pentru a vedea dacă comportamentul schimbări.
  3. Dacă serverul de aliasul nu este definit pe machidon, Adauga alias pentru serverul de la care vă conectaţi. Când efectuaţi această sarcină, vă sunt, de asemenea, în mod explicit definirea protocolului şi opţional definirea Adresă IP şi portul.
Setaţi manual un nume Principal de serviciu pentru SQL Server
Pentru mai multe informaţii despre cum să setaţi manual un nume Principal de serviciu pentru SQL Server, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
319723Cum se utilizează autentificarea Kerberos în SQL Server
SSPI (SSPI) este interfaţa pentru securitate Microsoft Windows NT, care este utilizat pentru autentificarea Kerberos, şi sprijină schemă de autentificare NTLM securitate suport furnizorului. Autentificarea se produce la nivel de sistem de operare atunci când faceţi conecta la un domeniu de Windows. Autentificarea Kerberos este disponibil numai pe computerele bazate pe Windows 2000 care au autentificarea Kerberos activat şi că utilizaţi Active Directory.

SSPI este folosit doar pentru conexiuni TCP/IP, care sunt realizate prin utilizarea autentificării Windows. Autentificarea Windows este, de asemenea, cunoscut sub nume de sign-in de încredere conexiuni sau integrate de securitate. SSPI nu se utilizează Canale declarate sau conexiuni multi-protocol. Prin urmare, se poate evita problema prin configurarea clienților să se conecteze la un protocol decât TCP/IP.

Atunci când un SQL Serverul clientul încearcă să folosească integrate de securitate peste TCP/IP prize la o telecomandă computer care execută SQL Server, biblioteca-client SQL Server reţea utilizează SSPI API pentru a efectua Delegaţia de securitate. SQL Server reţea client (Dbnetlib.dll) face un apel sosit la AcquireCredentialsHandle funcţie şi trece în "negocia" pentru parametrul pszPackage . Aceasta notifică care stau la baza furnizor de securitate pentru a efectua negocia delegaţiei. În acest context, negocia mijloacele să încercaţi autentificare sau Kerberos, NTLM pe computerele bazate pe Windows. Cu alte cuvinte, Windows utilizează delegare Kerberos în cazul în care computerul destinație care execută SQL Server are un asociat, configurat corect SPN. În caz contrar, Windows utilizaţi NTLM delegaţie.

Notă Verificaţi că nu utilizaţi un cont denumit "Sistem" pentru a începe oricare dintre serviciile SQL Server (MSSQLServer, SQLServerAgent, MSSearch). The cuvinte cheie sistem poate cauza conflicte cu cheie de distribuţie Center (KDC).

Colecta informaţii pentru a deschide un caz Microsoft Customer Support (CSS)

În cazul în care nu poate obţine cauza problema utilizând paşii de depanare din acest articol, colecta următoarele informaţii şi deschideţi un caz Microsoft Customer Support (CSS).

Pentru o listă completă a numerelor de telefon Microsoft de asistenţă pentru clienţi şi informaţii privind costurile de suport, du-te la următorul site Web Microsoft:
  1. Generează un raport de sqldiag din SQL Server. Pentru mai multe informaţii, consultaţi subiectul "sqldiag utilitate" în cărţi de Server SQL On-line.
  2. Captura un ecran shot de eroare pe client.
  3. Deschideţi un prompt de comandă pe nodul care nu se poate conecta la SQL Server, şi apoi tastaţi următoarea comandă:
    net scrobeală > started.txt
    Această comandă generează un fişier numit Started.txt în directorul unde executaţi comanda.
  4. A salva valorile pentru cheie de registry, sub următoarea cheie de registry de pe computerul client:
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. Într-un cluster găsi valoarea din următoarea cheie de registry pentru fiecare nod al clusterului:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. Într-un mediu grupate, a se vedea dacă următoarea cheie de registry există pe fiecare nodul de cluster server:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. Rezultatele de captare, în cazul în care vă conectaţi la SQL Server folosind un Universitate Naming Convention (UNC) nume de sign-in (sau nume de sign-in de reţea SQL într-un cluster) la client.
  8. Captura rezultatele dacă ping nume de sign-in computerului (sau nume de sign-in de reţea SQL într-un cluster) la client.
  9. Salva nume de sign-in de conturi de utilizator pe care le utilizaţi pentru a începe fiecare dintre serviciile SQL Server (MSSQLServer, SQLServerAgent, MSSearch).
  10. Suport profesionist trebuie să ştie dacă SQL Server este configurat pentru autentificarea mixte sau doar autentificare Windows.
  11. A se vedea dacă vă puteţi conecta la computer care execută SQL Server la acelaşi client utilizând autentificarea de Server SQL.
  12. A se vedea dacă vă puteţi conecta utilizând Protocolul de canale declarate.

Referințe

Pentru mai multe informaţii despre cum Kerberos autentificare şi SSPI lucrări de securitate, faceţi clic pe următoarele numere de articol pentru a vizualiza articolele în bază de cunoştinţe Microsoft:
266080Răspunsuri la întrebări frecvente de autentificare Kerberos
231789 Procesul de conecta locale pentru Windows 2000
304161 Autentificarea reciprocă SSPI este indicat pe partea de client, dar nu pe partea de server
232179 Kerberos administrare în Windows 2000
230476 Descrierea comune erori legate de Kerberos în Windows 2000
262177 Cum la spre enable Kerberos Eveniment Jurnalizarea
277658 Setspn nu reuşeşte dacă nume de sign-in de domeniu diferă de nume NetBIOS în cazul în care este înregistrat SQL Server SPN
244474 Cum la spre force Kerberos a utiliza TCP în loc UDP Windows Server 2003, Windows XP şi Windows 2000
326985 Cum se depanează problemele legate de Kerberos în IIS
Pentru a vedea o carte albă despre securitate Microsoft SQL Server 2000, du-te la următorul site Web Microsoft:

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 811889 - Ultima examinare: 04/05/2013 23:21:00 - Revizie: 4.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 64-bit Edition, Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Enterprise Evaluation, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Express with Advanced Services, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Express with Advanced Services, Microsoft SQL Server 2008 R2 Integration Services, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Standard Edition for Small Business, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2008 Reporting Services, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Standard Edition for Small Business, Microsoft SQL Server 2008 Web, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, SQL Server 2012 Enterprise Core

  • kbsqlsetup kbhowtomaster kbhowto kbsmbportal kbmt KB811889 KbMtro
Feedback
ementsByTagName("head")[0].appendChild(m);