Veți primi un "Warning SuperSocket Info" informații de avertizare atunci când un cont de serviciu SQL Server este un utilizator de domeniu

Traduceri articole Traduceri articole
ID articol: 303411 - View products that this article applies to.
BUG #: 232774 (SHILOH_BUGS)
Măriți totul | Reduceți totul

Simptome

Când pornește pe un computer care execută SQL Server Microsoft SQL Server 2000 sau Microsoft SQL Server 2005, programul de SQL Server întotdeauna încearcă să se înregistreze virtual server în Active Directory. Următorul eveniment pot fi înregistrate în Jurnalul de evenimente:

SuperSocket informații: (SpnRegister): eroare 8344 SuperSocket Info: (SPNRegister): eroare 1355 SuperSocket informatii: SpnUnRegister(): eroare 8344.

NotăEroare 1355 este egal cu ERROR_NO_SUCH_DOMAIN. Eroare 8344 este egal cu insuficiente permisiuni pentru a efectua operațiunea de înregistrare. Acest lucru este indicat ca un avertisment pentru funcția de SPNRegister și ca o eroare pentru funcția de SpnUnRegister .

Acest mesaj nu este un mesaj de eroare. Acest text este doar o avertisment că SQL Server nu poate înregistra un nume principal de serviciu (SPN). Acest lucru indică faptul că este mecanismul de securitate care vor fi utilizate Challenge\Response Microsoft pentru Windows NT (NTLM) autentificare în loc de Autentificarea Kerberos.

Aceste mesaje ar trebui considerate doar o problemă în cazul în care instalarea SQL Server necesită autentificarea Kerberos sau setările de securitate de rețea împiedică rezervă NTLM negocierea. În caz contrar, aceste mesaje pot fi ignorate în condiții de siguranță.

Cauză

Mesajul apare, de obicei, deoarece serviciul SQL Server contul se execută ca un utilizator de domeniu care nu are permisiunile necesare pentru a Registrul SPNs. Cu Microsoft Windows 2000 pachet Service Pack 3 (SP3), puteți activa Autentificarea Kerberos pe server de clustere. Pentru instrucțiuni despre cum să facă acest lucru, consultați următorul articol din bază de cunoștințe Microsoft:
319723 Informații despre SQL Server 2000 Kerberos de sprijin, inclusiv SQL Server fermă de servere virtuale pe serverul clustere

Rezoluție

Asemenea, puteți edita permisiunile de setările de Control acces cont din serviciul director Active Directory pentru a permite permisiunea citire NumePrincipalServiciu și scrie NumePrincipalServiciu permisiunea pentru contul de serviciu SQL.

Avertizare Dacă utilizați de completare snap-in Active Director Serviciul interfețe (ADSI) Edit, utilitarul LDP sau orice alți clienți de LDAP versiunea 3 și modificați incorect atributele obiectelor Active Directory, pot cauza probleme grave. Aceste probleme pot solicita ca reinstalarea Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, sau atât Windows și schimb. Microsoft nu poate garanta că problemele cauzate de modificarea incorect atributele obiectelor Active Directory poate fi rezolvată. Modifice aceste atribute la propriul risc.

Remediere

Pentru a rezolva aceste tip de mesaje și activați serviciul SQL Server pentru a crea SPNs dinamic pentru dumneavoastră cazuri de SQL Server, solicita?i administratorului de domeniu pentru a adăuga permisiunile corespunzătoare și drepturi utilizator în conturile de pornire a SQL Server.

Pentru a activa contul de serviciu SQL Server pentru a stabili SPNs corect la pornire, 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 ferestrei, extindeți Domeniu [Domeniului], extinde DC = RootDomainName, extinde NC = utilizatori, faceți clic dreapta pe NC =AccountName, apoi faceți clic pe Proprietăți.

    Note
    • Domeniului reprezintă nume de sign-in de domeniu.
    • RootDomainName este un substituent pentru nume de sign-in de domenii rădăcină.
    • AccountName reprezintă contul pe care îl specificați pentru a porni serviciul SQL Server.
    • Dacă ați specificat Sistemul Local pentru a porni serviciul SQL Server, AccountName reprezintă contul pe care le utilizați să faceți conecta Microsoft Windows.
    • Dacă ați specificat un cont de utilizator de domeniu pentru serviciul SQL Server, AccountName reprezintă 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ă utilizatorul de sine este listat sub Intrările de permisiune. În cazul în care utilizatorul de sine nu este listată, face?i clic pe Adauga, și apoi se adaugă utilizator de sine .
  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ă 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 închideți ADSI Edit fereastra.
Pentru ajutor cu acest proces, contactați asistență de produs Active Directory. Consultați acest articol din bază de cunoștințe Microsoft dacă să contactați asistență de produs.

Când efectuați această soluție, se elimina problemele SPN pentru instalații noi sau instalatii care au avut TCP/IP port sau domeniu nume modificat.

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.

Stare

Microsoft a confirmat că aceasta este o problemă în SQL Server 2000 și SQL Server 2005.

Referințe

Pentru mai multe informații, faceți clic pe următoarele numere de articol pentru a vedea articolele în bază de cunoștințe Microsoft:
235529Suport Kerberos pe clustere bazate pe Windows 2000 server
269229 Cum să recreați manual contul de serviciu Cluster

Proprietă?i

ID articol: 303411 - Ultima examinare: 7 aprilie 2013 - Revizie: 2.0
Se aplică la:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
Cuvinte cheie: 
kbbug kbpending kbmt KB303411 KbMtro
Traducere automată
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: 303411

Trimite?i feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com