SQL Server 2012 cu contul NT ServiceMSSQLSERVER accesul este refuzat în domeniu (Administrarea sistemului, Server Sql, Sql Server 2008, Domeniu, Permisiuni)

unruledboy a intrebat.
a intrebat.

În urmă cu câteva luni am instalat SQL Server 2012 în Windows 2008 R2 sub contul virtual „NT ServiceMSSQLSERVER„, totul în regulă.

În urmă cu câteva zile, unul dintre administratorii departamentului IT a instalat componenta Full Text Search la SQL Server 2012 (problema este că nu-și mai amintește ce setări anume a ales în timpul instalării), iar după aceea, vin destul de multe probleme:

A. Am verificat jurnalele Windows, în Aplicație, am aflat că MSSQLServer are destul de multe jurnale anormale, cum ar fi:

Biblioteca de interfață de rețea SQL Server nu a putut înregistra Service Principal Name (SPN) [ MSSQLSvc/FooComputer.FooDomain.com:1433 ] pentru serviciul SQL Server. Codul de returnare Windows: 0xffffffffffff, stare: 63. Eșecul înregistrării unui SPN ar putea face ca autentificarea integrată să utilizeze NTLM în loc de Kerberos. Acesta este un mesaj informativ. Este necesară o acțiune suplimentară numai dacă autentificarea Kerberos este cerută de politicile de autentificare și dacă SPN-ul nu a fost înregistrat manual.

Se pare că aceasta este cauza, dar nu am idee de ce și cum să o rezolvăm.

B. Lucrările SQL cu proprietari care sunt utilizatori de domeniu, cum ar fi („MyDomainFooUser”), vor eșua cu următorul mesaj:

Job-ul a eșuat. Nu se poate determina dacă proprietarul (MyDomainFooUser) al jobului JOBNAME are acces la server (motiv: Nu s-a putut obține informații despre grupul/utilizatorul Windows NT „MyDomainFooUser”, cod de eroare 0x6e. [SQLSTATE 42000] (Eroare 15404)).

Am făcut căutări intensive și, în cele din urmă, am înlocuit proprietarul cu „sa” și am rezolvat problema, deși nu este atât de decent. Totuși, am dori să aflăm de ce.

C. Nu se poate accesa resursele de rețea, cum ar fi un folder în alte calculatoare, de exemplu, următorul sql va returna „access is denied”:

DECLARE @CopyCommand nvarchar(1000)
set @CopyCommand = 'dir ' + Char(34) + '\FooComputerFooFolder' + Char(34)
EXEC master..xp_cmdshell @CopyCommand

Pentru problema C, conform MSDN (http://technet.microsoft.com/en-us/library/ms143504.aspx) am încercat să acordăm acces de control total pentru contul „MyDomainSQLServerComputerName$” la folder, tot același rezultat.

3 răspunsuri
SqlRyan

Aceste trei probleme sunt toate rezultatul faptului că contul care rulează serviciul SQL nu este un cont de domeniu și toate vor fi corectate prin modificarea SQL pentru a rula sub un cont de domeniu. Mai exact:

A – un SPN este o caracteristică de securitate Kerberos care necesită un cont de domeniu și nu funcționează cu conturi locale

B – pentru a citi din Active Directory, serviciul are nevoie de acreditările unui cont de domeniu

C – conturile locale nu sunt recunoscute de calculatoarele de la distanță, astfel încât acestea refuză încercarea de conectare.

Iată o prezentare generală a modului de modificare a contului de serviciu:

http://technet.microsoft.com/en-us/library/ms345578.aspx

Comentarii

  • Dar ceea ce m-a derutat este că de 2 luni totul funcționează bine din prima zi sub contul virtual „NT ServiceMSSQLSERVER”. De ce brusc nu mai funcționează? Și am făcut același lucru pentru SQL Server 2008 în Windows 2008 timp de ani de zile, tot fără probleme. –  > Por unruledboy.
  • Vrei să spui că a fost setat să folosească contul de serviciu anterior și a funcționat fără probleme? Din câte am înțeles, acest lucru nu este posibil – contul de serviciu este local la mașină și nu se va autentifica pe alte servere/ stații de lucru (decât dacă poate ca și cont de invitat, care este de obicei dezactivat). Trecerea la un cont de domeniu proxy este calea de urmat în orice caz și metoda recomandată atunci când serviciul dvs. sql trebuie să comunice cu alte mașini din domeniu. –  > Por SqlRyan.
  • Perfect. Acest lucru m-a ajutat să-mi fac treaba într-o clipită. –  > Por miCRoSCoPiCaRthLinG.
StiffBoard

Întrebare veche, dar nu pare să aibă un răspuns adecvat. NT ServiceMSSQLSERVER fiind un cont virtual local, acesta accesează rețeaua ca și contul de calculator. Atâta timp cât contul de calculator are acces la partaje și sisteme de fișiere, ar trebui să puteți, de exemplu, să faceți copii de rezervă pe căi UNC din rețea. A se vedea Configurarea conturilor și permisiunilor pentru servicii Windows.

user250187

Când ne-am confruntat cu această problemă, rezolvarea noastră a fost să localizăm folderul și să adăugăm permisiunile necesare pentru contul virtual care are nevoie de acesta. După ce am adăugat contul, prin simpla tastare a acestuia, am monitorizat fișierele jurnal și am constatat că nu mai aveam nicio problemă în ceea ce privește acest dosar/carte.