Eroare ‘The’account is not authorized to login from this station’ în timp ce încercați să accesați partajarea rețelei (Administrarea sistemului, Director Activ, Windows Server 2008 R2, Windows 7, Domeniu)

poke a intrebat.
a intrebat.

Clienții primesc această eroare atunci când încearcă să acceseze partajele de rețea pe unul unul dintre serverele noastre 2008 R2:

The account is not authorized to login from this station.

Problema a început în urmă cu câteva săptămâni. Este intermitentă pentru fiecare client în parte și poate dura ore sau zile. Problema nu afectează toți clienții în același timp.

De exemplu, în această dimineață, un client a funcționat, iar acum nu mai funcționează; un alt client nu a funcționat mai devreme, iar acum funcționează. Am observat această problemă atât la clienții Windows 7 Pro, cât și la alte cutii Windows Server 2008 R2 care încearcă să se conecteze ca și client la partajele serverului afectat.

Am încercat să mă conectez la share-ul C$ admin și se întâmplă același lucru:

Singurele rezultate de căutare pe care le obțin de pe internet și de la Microsoft se referă la probleme cu W2K. Nu există nimic de interes relevant în jurnalele de evenimente, nici pe server, nici pe clienți. Ce ar trebui să încerc în continuare?

Editați pentru a furniza informațiile solicitate:

Acest lucru afectează doar un singur server. Avem alte două servere în domeniul nostru care oferă partaje de rețea. Partajările de pe aceste servere sunt solide ca piatra 24×7. Nu există niciun fel de probleme de acces.

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : HOSTHV02
   Primary Dns Suffix  . . . . . . . : dc.XXXXXXXXXXX.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : dc.XXXXXXXXXXX.com

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
   Physical Address. . . . . . . . . : 90-B1-1C-17-06-DE
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::d5b:157:2c8a:99a4%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.4.32(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.4.1
   DHCPv6 IAID . . . . . . . . . . . : 244363548
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-76-57-7E-90-B1-1C-17-06-DE

   DNS Servers . . . . . . . . . . . : 192.168.4.16
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{54A6F175-C7D4-4C3E-BCA8-2F4DF4F4CB4D}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Editați

Acest lucru nu pare să fie cauzat de politici de semnare nepotrivite. Problema continuă să afecteze „la întâmplare” calculatoarele client. De exemplu, săptămâna aceasta, stația mea de lucru nu a putut accesa partajările într-o zi, a putut în următoarea, iar în ziua următoare nu a mai putut din nou.

Comentarii

  • Se întâmplă doar pe acel 1 server 2008 R2? Celelalte servere cu partaje sunt accesibile 24/7? Puteți edita întrebarea dvs. și să postați detaliile complete ale unei ipconfig /all a serverului în cauză, precum și un gpresult /SCOPE COMPUTER /v –  > Por TheCleaner.
  • @TheCleaner: Mi-am actualizat răspunsul. Este vorba doar de acest server. Alte partaje de pe alte servere sunt în regulă. Ieșirea din gpresult este prea lungă pentru a fi postată. Există o anumită secțiune pe care o căutați? –  > Por poke.
  • Gpresult a fost pentru a verifica dacă există vreun fel de GP care ar afecta serverul diferit de celelalte. Dacă sunteți sigur că toate primesc aceleași politici și că problemele din răspunsurile de mai jos nu sunt ceea ce se întâmplă, putem continua săpăturile. De asemenea, ați spus că ați încercat să vă conectați la C$, ce se întâmplă dacă deschideți compmgmt.msc și faceți clic dreapta și încercați să administrați de la distanță acel server? Funcționează cu acreditările dvs. sau nu? –  > Por TheCleaner.
  • @TheCleaner. Pot să mă conectez prin intermediul snap-in-ului Computer Management și să vizualizez diverse elemente (Servicii, Fișiere deschise/sesiuni, etc.). –  > Por poke.
3 răspunsuri
Mathias R. Jessen

După cum v-ar fi spus toate articolele legate de Windows 2000, dacă le-ați fi citit, această eroare apare atunci când clientul și serverul au configurate politici de semnare SMB conflictuale.

Și anume, serverul încearcă să impună SMB Signing, dar clientul fie refuză, fie nu poate negocia SMB Signing cu serverul

Aceste setări pot fi definite utilizând fie Local Group Policy (gpedit.msc) sau Group Policy dacă utilizați Active Directory.

^ Acestea sunt probabil droizii pe care îi căutați

Comentarii

  • Această problemă este interment. Cum ar putea fi intermentul politicile de semnare conflictuale? Se pare că ar funcționa sau nu ar funcționa tot timpul. În acest moment, problema pare să se deplaseze între clienții care se conectează la acest server. –  > Por poke.
  • @poke – Sunt de acord că se pare că problema nu ar fi intermitentă dacă aceasta ar fi cauza. Totuși, cred că ar fi înțelept să verificați setările menționate în răspunsul oferit de Mathias, dacă nu altceva decât pentru a exclude această problemă. –  > Por joeqwerty.
  • @joeqwerty: Dintre cele patru politici evidențiate în captura de ecran, doar clientul de rețea Microsoft: Semnează digital comunicațiile (dacă serverul este de acord) este Activată. Celelalte trei sunt dezactivate. Aceste setări sunt aceleași pe server și pe client. –  > Por poke.
poke

Înregistrări DNS incorecte

Iată soluția noastră pentru această situație specială:

Serverul nostru DNS avea două înregistrări DNS A pentru serverul problematic. O înregistrare avea adresa IP corectă, iar cealaltă avea o adresă diferită. După ce am șters înregistrarea greșită, problema a dispărut. Înregistrarea greșită avea un timestamp din jurul datei la care a început această problemă. În acest moment, nu sunt sigur cum a ajuns înregistrarea acolo, dar cred că a fost o actualizare dinamică.

În prezent, sunt în curs de a configura un sistem de curățare pe serverele noastre DNS.

Brandon Lawson

Așa cum spune Mathias, verificați semnarea SMB între cele două servere, mă gândesc și eu că nu s-au potrivit unul cu celălalt.

Verificați aceste setări pe stația de lucruserver.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanworkstationparameters

  • enablesecuritysignature = 1
  • requiresecuritysignature = 0

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparametri

  • enablesecuritysignature = 1
  • requiresecuritysignature = 0

Vă recomand să activați și următoarele prin GPO.

Setări ale politicii Microsoft Network Client Policy

  • Client de rețea Microsoft: Semnarea digitală a comunicațiilor (întotdeauna)Activat
  • Clientul de rețea Microsoft: Semnarea digitală a comunicațiilor (dacă serverul este de acord) Activat