SMB 2240 via VPN: de lijst met aanmeldwerkstations controleren

Een share via de tunnel openen geeft fout 2240, en de eerste reflex is naar de routering kijken. Het nummer is specifieker dan dat. Windows meldt dat het account zich mogelijk niet vanaf dit werkstation kan aanmelden, wat een beleidsuitspraak over één account is en geen uitspraak over bereikbaarheid.

Bewaar het foutnummer in het ticket. Het beperkt het onderzoek tot één attribuut en één gebeurtenis.

Wat 2240 eigenlijk benoemt

De foutlijst van netwerkbeheer identificeert 2240 als NERR_InvalidWorkstation, een naam die je letterlijk moet lezen. Het account is beperkt tot een reeks toegestane aanmeldcomputers, en de machine die de referenties aanbiedt hoort daar niet bij. Niets in die definitie noemt de tunnel, de bestandsshare of het wachtwoord. Het attribuut staat op het account en wordt beoordeeld wanneer de aanmelding wordt geprobeerd.

Andere nummers uit dezelfde familie betekenen iets anders. Een overtreding van de toegestane aanmeldtijden is een andere code, en een verkeerd wachtwoord ook. Ze allemaal als toegangsprobleem melden verspilt de specificiteit die het besturingssysteem zojuist gaf.

De beperking woont op het account, dus volgt ze de identiteit overal waar die zich authenticeert. Een gebruiker die elke dag op kantoor werkt en een laptop mee naar huis neemt, komt haar alleen tegen wanneer de machinenaam verandert, en daarom kan de storing maandenlang op een VPN-probleem lijken voordat iemand het patroon herkent.

Twee verwante feiten verklaren het niet. Een NAT-apparaat kan het waargenomen bronadres wijzigen zonder het accountattribuut aan te raken, en een wijziging van het DNS-suffix kan een korte naam repareren terwijl de aanmeldbeperking precies blijft waar ze was. Beide zijn het waard uit te sluiten, en geen van beide vervangt het lezen van het attribuut.

Lees eerst het record van de mislukte aanmelding

Stel vast welke identiteit de bestandsserver heeft geauthenticeerd, en welke machine die heeft aangeboden. Een domeinaccount, een lokaal account met een vergelijkbare korte naam en een apart VPN-account zijn niet uitwisselbaar, en de fout is alleen zinvol als de exacte bekend is.

Het beveiligingslogboek legt de poging vast met het account en de naam van het aanroepende werkstation, en precies dat paar wordt tegen de beperking getoetst:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
  Select-Object SamAccountName,LogonWorkstations

De eerste opdracht toont de storing en de werkstationreeks die de server ontving, de tweede toont de toegestane lijst op het account. Vergelijk de twee in plaats van aan te nemen dat de computernaam van de client is wat de server heeft vastgelegd. Een naam die in het logboek verkeerd lijkt, is meestal de nuttige vondst, omdat hij de machine benoemt waarmee de server werkelijk denkt te praten. Het is die overtuiging waartegen de beperking wordt gecontroleerd.

Voeg de naam van de VPN-gateway niet toe omdat het verkeer erdoorheen gaat. De gateway is niet de geauthenticeerde aanroeper, en hem aan de lijst toevoegen verandert niets terwijl het account moeilijker te beoordelen wordt.

Herstel de beperking op de kleinste omvang

Als de machine moet worden toegestaan, voeg dan precies die vermelding toe aan de werkstationlijst van het account en laat al het andere ongemoeid. Als dat niet moet, is het juiste antwoord een goedgekeurde machine in plaats van het verwijderen van de beperking, omdat de beperking bestaat om te begrenzen waar die referenties mogen worden gebruikt.

Bulkbewerkingen zijn hier gebruikelijk en meestal onjuist. Een account met een lange lijst toegestane machines is een account waarvan de beperking niets meer betekent.

Het helpt ook te weten of de identiteit gedeeld is. Wanneer meerdere mensen één serviceaccount vanaf meerdere laptops gebruiken, groeit de werkstationlijst tot het beleid zinloos is, wat een ontwerpprobleem is en geen administratief probleem.

Lees het volgende resultaat, niet het ontbreken ervan

Maak na een goedgekeurde wijziging een nieuw verzoek met het bedoelde account en noteer wat er gebeurt. Een andere fout is vooruitgang, omdat die de volgende fase benoemt in plaats van de vorige te herhalen.

Een DFS-pad kan meerdere servers en meerdere toegangsbeslissingen binnenhalen. Het opschonen van één accountattribuut lost er één van op. De verwijzingsdoelen moeten nog steeds bereikbaar zijn, en de share- en bestandssysteemrechten op elk daarvan moeten het account nog steeds toelaten. Werk de volgende fout op dezelfde manier door in plaats van aan te nemen dat de eerste correctie ze allemaal dekte.

Er is geen reden om het VPN-profiel opnieuw op te bouwen of het wachtwoord opnieuw in te stellen terwijl Windows een werkstationbeperking meldt. De lijst met netwerkfouten van Microsoft is het waard open te houden precies om deze reden: de code vertelt je welk attribuut je moet inspecteren voordat je iets aanraakt.