Anslut en VPN-filresurs med det Samba-konto som servern känner till

Anslut tunneln och resursen frågar fortfarande efter ett lösenord som användaren tror är rätt. I en fristående Samba-installation är VPN-inloggningen och SMB-inloggningen oberoende inloggningsuppgifter: den ena auktoriserar tunneln, den andra kontrolleras av filservern. Att ansluta enheten med VPN-kontot misslyckas därför även när lösenordet är rätt och nätverkssökvägen är perfekt. Den skillnaden förklarar de flesta anslutningsfel över en VPN.

Lösningen är inte att återställa VPN-kontot. Den är att namnge en identitet som Samba-servern faktiskt känner till och sedan kontrollera att samma identitet har rättigheter till resursen och katalogen.

VPN-inloggningen och SMB-inloggningen är olika identiteter

Ett VPN-konto utvärderas av VPN-gatewayen enligt dess egen policy. Det svarar på om den här klienten får gå in i det privata nätverket. Det säger inget om vilket SMB-konto som finns på en filserver i det nätverket.

Ett Samba-konto ligger i serverns autentiseringsbackend med egen lösenordsdatabas och eget namn. Två maskiner kan båda ha en användare som heter alice utan att dela identitetssystem, lösenord eller användar-id. Namnen stämmer; kontona gör det inte.

En domänintegrerad Samba-server ändrar bilden: identiteten kommer från katalogen och från Kerberos, inte från en lokal kontolista. Använd i så fall katalogidentiteten och den SMB-konfiguration som stöds i stället för att skapa lokala dubbletter för att imitera domänmedlemskap. Kontrollera vilken modell servern använder innan du skapar något konto.

Se vilken identitet Windows faktiskt använder

Windows cachar anslutningar per server. Om en befintlig session till samma server öppnades med ett annat konto kan en ny anslutning återanvända sessionen eller misslyckas med ett autentiseringsfel som namnger fel användare. Så ser ett korrekt lösenord ut att vara fel. Granska de aktuella anslutningarna innan du ändrar inloggningsuppgifter.

net use
cmdkey /list
klist

Det första kommandot visar anslutna enheter och öppna sessioner, det andra visar sparade inloggningsuppgifter som kan tillämpas automatiskt, och det tredje visar Kerberos-biljetter när en domän används. En sparad inloggningsuppgift kan tysta åsidosätta det konto du tänkte skriva.

Ta bara bort den anslutning eller de inloggningsuppgifter som hör till det här problemet. Att koppla bort alla enheter eller ersätta servernamnet med en IP-adress döljer identitetsvalet och kan bryta signering eller namnebaserad policy.

Anslut resursen med det konto servern känner igen

Ange kontot i den form servern förväntar sig och låt Windows fråga efter lösenordet, så att hemligheten inte hamnar i kommandohistoriken eller ett skript:

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

Serverdelen före det omvända snedstrecket är Samba-serverns identitetskontext, inte VPN-gatewayen. Stjärnan begär en interaktiv lösenordsfråga, och /persistent:no håller anslutningen borta från nästa inloggning. Välj en ledig enhetsbokstav.

Om servern är domänintegrerad kan användardelen i stället vara ett katalognamn eller en domänkvalificerad identitet. Använd den form administratören dokumenterar; att hitta på ett lokalt konto med samma namn skapar en andra identitet och ett andra lösenord att underhålla.

Kontogiltighet, resursåtkomst och filsystemrättigheter är tre kontroller

Samba kontrollerar om identiteten autentiseras, om resursdefinitionen släpper in den, och om filsystemet beviljar den begärda åtgärden. Att klara den första kontrollen innebär inte att de andra två också klaras. En resurs kan vara synlig och ändå vägra skrivningar eftersom katalogbehörigheterna säger det.

En resurs som begränsas med valid users släpper bara in de angivna kontona eller grupperna. Kontot kan autentiseras korrekt och ändå avvisas av den raden. Kontrollera resursdefinitionen innan du drar slutsatsen att lösenordet är fel.

På filsystemssidan spelar både Samba-processen och den anslutna identiteten roll. En katalog som ägs av root med läge 700 accepterar inte skrivningar från ett vanligt konto, även när resursdefinitionen tillåter det. Testa med en läsning och sedan en skrivning i en katalog som kontot ska använda.

Rensa en konfliktande session utan att bryta policyn

När en inaktuell session är orsaken stänger du den ena anslutningen och ansluter igen med det avsedda kontot. Om en sparad inloggningsuppgift fortsätter att komma tillbaka tar du bort den uppgiften i stället för hela enhetslistan. Bekräfta sedan den nya sessionen med net use.

Behåll den nödvändiga SMB-signeringen, krypteringen och kontopolicyn. En server som vägrar en osignerad eller okrypterad session genomdriver policy och läser inte lösenordet fel, och att försvaga den för att anslutningen ska lyckas byter säkerhet mot ett symptom.

Anteckna servernamnet, den exakta kontoformen och de resurs- och katalogrättigheter som fungerade. Nästa person som ansluter enheten försöker annars VPN-inloggningen först, eftersom det är uppgifterna de nådde nätverket med.