SMB 2240 över VPN: kontrollera listan över inloggningsarbetsstationer

Fel 2240 betyder att kontot kanske inte kan logga in från den arbetsstationen. Läs posten om misslyckad inloggning och rätta kontot, inte DNS eller tunneln.

När en delning öppnas genom tunneln returneras fel 2240, och den första instinkten är att titta på routningen. Numret är mer specifikt än så. Windows rapporterar att kontot kanske inte kan logga in från den här arbetsstationen, vilket är ett policyuttalande om ett konto och inte ett uttalande om nåbarhet.

Behåll felnumret i ärendet. Det begränsar undersökningen till ett attribut och en händelse.

Vad 2240 egentligen benämner

Fellistan för nätverksadministration identifierar 2240 som NERR_InvalidWorkstation, ett namn som är värt att läsa bokstavligt. Kontot är begränsat till en uppsättning tillåtna inloggningsdatorer, och maskinen som presenterar autentiseringsuppgifterna finns inte bland dem. Inget i den definitionen nämner tunneln, filresursen eller lösenordet. Attributet sitter på kontot och utvärderas när inloggningen försöks.

Andra nummer i samma familj betyder något annat. Brott mot tillåtna inloggningstider är en annan kod, och detsamma gäller ett felaktigt lösenord. Att rapportera dem alla som ett åtkomstproblem slösar bort den specificitet som operativsystemet just gav.

Begränsningen bor på kontot, så den följer identiteten varhelst den autentiseras. En användare som arbetar på kontoret varje dag och tar med en bärbar dator hem stöter på den bara när maskinnamnet ändras, och därför kan felet i månader se ut som ett VPN-problem innan någon känner igen mönstret.

Två relaterade fakta förklarar det inte. En NAT-enhet kan ändra den observerade källadressen utan att röra kontoattributet, och en ändring av DNS-suffixet kan rätta ett kort namn medan inloggningsbegränsningen stannar exakt där den var. Båda är värda att utesluta, och ingen av dem ersätter att läsa attributet.

Läs posten om misslyckad inloggning först

Fastställ vilken identitet filservern autentiserade, och vilken maskin som presenterade den. Ett domänkonto, ett lokalt konto med liknande kort namn och ett separat VPN-konto kan inte bytas mot varandra, och felet ger bara mening när det exakta är känt.

Säkerhetsloggen registrerar försöket med kontot och namnet på den anropande arbetsstationen, och det är just det paret som begränsningen utvärderas 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

Det första kommandot visar felet och den arbetsstationssträng som servern tog emot, och det andra visar den tillåtna listan på kontot. Jämför de två i stället för att anta att klientens eget datornamn är det servern registrerade. Ett namn som ser fel ut i loggen är oftast det användbara fyndet, eftersom det namnger den maskin som servern faktiskt tror att den talar med. Det är den tron som begränsningen kontrolleras mot.

Lägg inte till VPN-gatewayens namn för att trafiken passerar den. Gatewayen är inte den autentiserade anroparen, och att lägga till den i listan ändrar ingenting men gör kontot svårare att granska.

Rätta begränsningen i den minsta omfattningen

Om maskinen ska tillåtas, lägg till exakt den posten i kontots arbetsstationslista och lämna allt annat orört. Om inte, är det rätta svaret en godkänd maskin i stället för att ta bort begränsningen, eftersom begränsningen finns för att begränsa var dessa autentiseringsuppgifter får användas.

Massredigeringar är vanliga här och oftast fel. Ett konto med en lång lista över tillåtna maskiner är ett konto vars begränsning har slutat betyda något.

Det hjälper också att veta om identiteten är delad. När flera personer använder ett tjänstekonto från flera bärbara datorer växer arbetsstationslistan tills policyn blir meningslös, vilket är ett designproblem och inte ett administrativt.

Läs nästa resultat, inte frånvaron av det

Efter en godkänd ändring, gör en ny begäran med det avsedda kontot och notera vad som händer. Ett annat fel är framsteg, eftersom det namnger nästa steg i stället för att upprepa det förra.

En DFS-sökväg kan föra in flera servrar och flera åtkomstbeslut. Att rensa ett kontoattribut avgör ett av dem. Hänvisningsmålen måste fortfarande vara nåbara, och delnings- och filsystembehörigheterna på var och en av dem måste fortfarande släppa in kontot. Arbeta igenom nästa fel på samma sätt i stället för att anta att den första rättelsen täckte alla.

Det finns ingen anledning att bygga om VPN-profilen eller återställa lösenordet medan Windows rapporterar en arbetsstationsbegränsning. Microsofts lista över nätverksfel är värd att hålla öppen just av den här anledningen: koden berättar vilket attribut du ska undersöka innan du rör något.

Relaterade artiklar