Knyt en VPN-fildeling til med den Samba-konto, serveren kender

Opret tunnelen, og delingen beder stadig om en adgangskode, som brugeren mener er korrekt. I en selvstændig Samba-installation er VPN-logonet og SMB-logonet uafhængige legitimationsoplysninger: det ene autoriserer tunnelen, det andet kontrolleres af fileserveren. At knytte drevet til med VPN-kontoen mislykkes derfor, selv når adgangskoden er rigtig, og netværksstien er perfekt. Den forskel forklarer de fleste tilslutningsfejl over en VPN.

Løsningen er ikke at nulstille VPN-kontoen. Den er at navngive en identitet, som Samba-serveren faktisk kender, og derefter kontrollere, at den samme identitet har rettigheder til delingen og mappen.

VPN-logonet og SMB-logonet er forskellige identiteter

En VPN-konto vurderes af VPN-gatewayen efter dens egen politik. Den svarer på, om denne klient må gå ind i det private netværk. Den siger intet om, hvilken SMB-konto der findes på en fileserver i det netværk.

En Samba-konto ligger i serverens godkendelses-backend med sin egen adgangskodedatabase og sit eget navn. To maskiner kan begge have en bruger ved navn alice uden at dele et identitetssystem, en adgangskode eller et bruger-id. Navnene stemmer; kontoene gør ikke.

En domæneintegreret Samba-server ændrer billedet: identiteten kommer fra mappen og fra Kerberos, ikke fra en lokal kontoliste. Brug i så fald mappeidentiteten og den understøttede SMB-konfiguration i stedet for at oprette lokale dubletter for at efterligne domænemedlemskab. Kontrollér, hvilken model serveren bruger, før du opretter en konto.

Se, hvilken identitet Windows faktisk bruger

Windows cacher forbindelser for hver server. Hvis en eksisterende session til den samme server er åbnet med en anden konto, kan en ny tilslutning genbruge den session eller mislykkes med en godkendelsesfejl, der navngiver den forkerte bruger. Sådan kommer en korrekt adgangskode til at se forkert ud. Undersøg de aktuelle forbindelser, før du ændrer legitimationsoplysninger.

net use
cmdkey /list
klist

Den første kommando viser tilsluttede drev og åbne sessioner, den anden viser gemte legitimationsoplysninger, der kan anvendes automatisk, og den tredje viser Kerberos-billetter, når et domæne er i brug. En gemt legitimationsoplysning kan lydløst tilsidesætte den konto, du havde tænkt dig at skrive.

Fjern kun den forbindelse eller de legitimationsoplysninger, der hører til dette problem. At afbryde alle drev eller erstatte servernavnet med en IP-adresse skjuler identitetsvalget og kan ødelægge signering eller navnebaseret politik.

Knyt delingen til med den konto, serveren genkender

Angiv kontoen i den form, serveren forventer, og lad Windows spørge efter adgangskoden, så hemmeligheden ikke havner i kommandohistorikken eller et script:

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

Serverdelen før omvendt skråstreg er Samba-serverens identitetskontekst, ikke VPN-gatewayen. Stjernen anmoder om en interaktiv adgangskodeprompt, og /persistent:no holder tilslutningen ude af næste logon. Vælg et ledigt drevbogstav.

Hvis serveren er domæneintegreret, kan brugerdelen i stedet være et mappenavn eller en domænekvalificeret identitet. Brug den form, administratoren dokumenterer; at opfinde en lokal konto med samme navn skaber en anden identitet og en anden adgangskode at vedligeholde.

Kontogyldighed, delingsadgang og filsystemrettigheder er tre kontroller

Samba kontrollerer, om identiteten godkendes, om delingsdefinitionen tillader den, og om filsystemet giver den ønskede handling. At bestå den første kontrol betyder ikke, at de to andre også bestås. En deling kan være synlig og alligevel afvise skrivninger, fordi mappetilladelserne siger det.

En deling, der er begrænset med valid users, tillader kun de anførte konti eller grupper. Kontoen kan godkendes korrekt og alligevel afvises af den linje. Kontrollér delingsdefinitionen, før du konkluderer, at adgangskoden er forkert.

På filsystemsiden betyder både Samba-processen og den tilsluttede identitet noget. En mappe, der ejes af root med tilstand 700, accepterer ikke skrivninger fra en almindelig konto, selv når delingsdefinitionen tillader det. Test med en læsning og derefter en skrivning i en mappe, som kontoen skal bruge.

Ryd en konfliktende session uden at bryde politikken

Når en forældet session er årsagen, skal du lukke den ene forbindelse og tilslutte igen med den tilsigtede konto. Hvis en gemt legitimationsoplysning bliver ved med at vende tilbage, skal du fjerne den oplysning i stedet for hele drevlisten. Bekræft derefter den nye session med net use.

Behold den krævede SMB-signering, kryptering og kontopolitik. En server, der afviser en usigneret eller ukrypteret session, håndhæver politik og læser ikke adgangskoden forkert, og at svække den for at få tilslutningen til at lykkes bytter sikkerhed for et symptom.

Notér servernavnet, den præcise kontoform og de delings- og mapperettigheder, der virkede. Den næste person, der tilslutter drevet, prøver ellers VPN-logonet først, fordi det er de legitimationsoplysninger, de nåede netværket med.