SMB 2240 over VPN: kontroller listen over påloggingsarbeidsstasjoner

Når en deling åpnes gjennom tunnelen, returneres feil 2240, og den første innskytelsen er å se på rutingen. Tallet er mer spesifikt enn det. Windows rapporterer at kontoen kanskje ikke kan logge på fra denne arbeidsstasjonen, noe som er en retningslinjeerklæring om én konto og ikke en erklæring om tilgjengelighet.

Behold feilnummeret i saken. Det avgrenser undersøkelsen til én attributt og én hendelse.

Hva 2240 egentlig benevner

Feillisten for nettverksadministrasjon identifiserer 2240 som NERR_InvalidWorkstation, et navn det er verdt å lese bokstavelig. Kontoen er begrenset til et sett med tillatte påloggingsdatamaskiner, og maskinen som legger frem legitimasjonen er ikke blant dem. Ingenting i den definisjonen nevner tunnelen, fildelingen eller passordet. Attributten sitter på kontoen og vurderes når pålogging forsøkes.

Andre numre i samme familie betyr noe annet. Brudd på tillatte påloggingstider er en annen kode, og det samme er et feil passord. Å rapportere dem alle som et tilgangsproblem kaster bort den spesifisiteten operativsystemet nettopp ga.

Begrensningen bor på kontoen, så den følger identiteten hvor den enn autentiseres. En bruker som jobber på kontoret hver dag og tar med en bærbar hjem, møter den bare når maskinnavnet endres, og derfor kan feilen i månedsvis se ut som et VPN-problem før noen gjenkjenner mønsteret.

To beslektede fakta forklarer det ikke. En NAT-enhet kan endre den observerte kildeadressen uten å røre kontoattributten, og en endring av DNS-suffikset kan rette et kort navn mens påloggingsbegrensningen blir nøyaktig der den var. Begge er verdt å utelukke, og ingen av dem erstatter å lese attributten.

Les oppføringen om mislykket pålogging først

Fastslå hvilken identitet filserveren autentiserte, og hvilken maskin som la den frem. En domenekonto, en lokal konto med et lignende kort navn og en separat VPN-konto kan ikke byttes om hverandre, og feilen gir bare mening når den nøyaktige er kjent.

Sikkerhetsloggen registrerer forsøket med kontoen og navnet på den kallende arbeidsstasjonen, og det er nettopp dette paret begrensningen vurderes mot:

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

Den første kommandoen viser feilen og arbeidsstasjonsstrengen serveren mottok, og den andre viser den tillatte listen på kontoen. Sammenlign de to i stedet for å anta at klientens eget datamaskinnavn er det serveren registrerte. Et navn som ser feil ut i loggen er vanligvis det nyttige funnet, fordi det navngir maskinen serveren faktisk tror den snakker med. Det er den troen begrensningen kontrolleres mot.

Ikke legg til VPN-gatewayens navn fordi trafikken går gjennom den. Gatewayen er ikke den autentiserte kalleparten, og å legge den til i listen endrer ingenting mens det gjør kontoen vanskeligere å gjennomgå.

Rett begrensningen i det minste omfanget

Hvis maskinen skal tillates, legg nøyaktig den oppføringen til kontoens arbeidsstasjonsliste og la alt annet være. Hvis ikke, er det riktige svaret en godkjent maskin i stedet for å fjerne begrensningen, fordi begrensningen finnes for å begrense hvor disse legitimasjonene kan brukes.

Masseredigering er vanlig her og vanligvis feil. En konto med en lang liste over tillatte maskiner er en konto der begrensningen har sluttet å bety noe.

Det hjelper også å vite om identiteten er delt. Når flere personer bruker én tjenestekonto fra flere bærbare datamaskiner, vokser arbeidsstasjonslisten til retningslinjen blir meningsløs, noe som er et designproblem og ikke et administrativt.

Les det neste resultatet, ikke fraværet av det

Etter en godkjent endring, send en ny forespørsel med den tiltenkte kontoen og noter hva som skjer. En annen feil er fremgang, fordi den navngir neste trinn i stedet for å gjenta det forrige.

En DFS-sti kan introdusere flere servere og flere tilgangsbeslutninger. Å rydde én kontoattributt avgjør én av dem. Referansemålene må fortsatt være tilgjengelige, og dele- og filsystemtillatelsene på hver av dem må fortsatt slippe kontoen inn. Arbeid deg gjennom den neste feilen på samme måte i stedet for å anta at den første rettelsen dekket alle.

Det er ingen grunn til å bygge VPN-profilen på nytt eller tilbakestille passordet mens Windows rapporterer en arbeidsstasjonsbegrensning. Microsofts liste over nettverksfeil er verdt å holde åpen nettopp av denne grunnen: koden forteller deg hvilken attributt du skal undersøke før du rører noe.