Koble en VPN-fildeling til med Samba-kontoen serveren kjenner

Koble opp tunnelen, og delingen spør fortsatt etter et passord som brukeren mener er riktig. I en frittstående Samba-installasjon er VPN-innloggingen og SMB-innloggingen uavhengige påloggingsdetaljer: den ene autoriserer tunnelen, den andre kontrolleres av filserveren. Å koble stasjonen til med VPN-kontoen mislykkes derfor selv når passordet er riktig og nettverksbanen er perfekt. Den forskjellen forklarer de fleste tilkoblingsfeil over en VPN.

Løsningen er ikke å tilbakestille VPN-kontoen. Den er å navngi en identitet Samba-serveren faktisk kjenner, og deretter kontrollere at den samme identiteten har rettigheter til delingen og katalogen.

VPN-innloggingen og SMB-innloggingen er forskjellige identiteter

En VPN-konto vurderes av VPN-gatewayen etter sin egen policy. Den svarer på om denne klienten får komme inn i det private nettverket. Den sier ingenting om hvilken SMB-konto som finnes på en filserver i det nettverket.

En Samba-konto ligger i serverens autentiseringsbackend med sin egen passorddatabase og sitt eget navn. To maskiner kan begge ha en bruker som heter alice uten å dele et identitetssystem, et passord eller en bruker-id. Navnene stemmer; kontoene gjør det ikke.

En domeneintegrert Samba-server endrer bildet: identiteten kommer fra katalogen og fra Kerberos, ikke fra en lokal kontoliste. Bruk i så fall katalogidentiteten og den støttede SMB-konfigurasjonen i stedet for å opprette lokale duplikater for å etterligne domenemedlemskap. Kontroller hvilken modell serveren bruker før du oppretter en konto.

Se hvilken identitet Windows faktisk bruker

Windows bufrer tilkoblinger per server. Hvis en eksisterende sesjon til samme server ble åpnet med en annen konto, kan en ny tilkobling gjenbruke sesjonen eller mislykkes med en autentiseringsfeil som navngir feil bruker. Slik kan et riktig passord se feil ut. Undersøk de gjeldende tilkoblingene før du endrer påloggingsdetaljer.

net use
cmdkey /list
klist

Den første kommandoen viser tilkoblede stasjoner og åpne sesjoner, den andre viser lagrede påloggingsdetaljer som kan brukes automatisk, og den tredje viser Kerberos-billetter når et domene er i bruk. En lagret påloggingsdetalj kan stille overstyre kontoen du hadde tenkt å skrive.

Fjern bare tilkoblingen eller påloggingsdetaljen som hører til dette problemet. Å koble fra alle stasjoner eller erstatte servernavnet med en IP-adresse skjuler identitetsvalget og kan bryte signering eller navnebasert policy.

Koble delingen til med kontoen serveren gjenkjenner

Oppgi kontoen i formen serveren forventer og la Windows spørre etter passordet, slik at hemmeligheten ikke havner i kommandohistorikken eller et skript:

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

Serverdelen før omvendt skråstrek er Samba-serverens identitetskontekst, ikke VPN-gatewayen. Stjernen ber om en interaktiv passordforespørsel, og /persistent:no holder tilkoblingen unna neste pålogging. Velg en ledig stasjonsbokstav.

Hvis serveren er domeneintegrert, kan brukerdelen i stedet være et katalognavn eller en domenekvalifisert identitet. Bruk formen administratoren dokumenterer; å finne opp en lokal konto med samme navn lager en andre identitet og et andre passord å vedlikeholde.

Kontogyldighet, delingstilgang og filsystemrettigheter er tre kontroller

Samba kontrollerer om identiteten autentiseres, om delingsdefinisjonen slipper den inn, og om filsystemet innvilger den forespurte operasjonen. Å bestå den første kontrollen betyr ikke at de to andre også bestås. En deling kan være synlig og likevel nekte skriving fordi katalogtillatelsene sier det.

En deling som er begrenset med valid users, slipper bare inn de oppførte kontoene eller gruppene. Kontoen kan autentiseres riktig og likevel avvises av den linjen. Kontroller delingsdefinisjonen før du konkluderer med at passordet er feil.

På filsystemsiden spiller både Samba-prosessen og den tilkoblede identiteten en rolle. En katalog som eies av root med modus 700 godtar ikke skriving fra en vanlig konto, selv når delingsdefinisjonen tillater det. Test med en lesing og deretter en skriving i en katalog kontoen skal bruke.

Rydd en motstridende sesjon uten å bryte policyen

Når en utdatert sesjon er årsaken, lukker du den ene tilkoblingen og kobler til igjen med den tiltenkte kontoen. Hvis en lagret påloggingsdetalj fortsetter å komme tilbake, fjerner du den detaljen i stedet for hele stasjonslisten. Bekreft deretter den nye sesjonen med net use.

Behold den påkrevde SMB-signeringen, krypteringen og kontopolicyen. En server som nekter en usignert eller ukryptert sesjon, håndhever policy og leser ikke passordet feil, og å svekke den for at tilkoblingen skal lykkes bytter sikkerhet mot et symptom.

Noter servernavnet, den nøyaktige kontoformen og delings- og katalogrettighetene som fungerte. Den neste personen som kobler stasjonen til, prøver ellers VPN-innloggingen først, fordi det er detaljene de nådde nettverket med.