Een VPN-bestandsmaps koppelen met het Samba-account dat de server kent

Maak de tunnel en de share vraagt nog steeds om een wachtwoord dat de gebruiker correct acht. In een zelfstandige Samba-implementatie zijn de VPN-login en de SMB-login onafhankelijke inloggegevens: de ene autoriseert de tunnel, de andere wordt door de bestandsserver gecontroleerd. De schijf koppelen met het VPN-account mislukt daarom zelfs wanneer het wachtwoord juist is en het netwerkpad perfect is. Dat onderscheid verklaart de meeste koppelfouten via een VPN.

De oplossing is niet het VPN-account opnieuw instellen. Het is een identiteit benoemen die de Samba-server echt kent, en vervolgens controleren of diezelfde identiteit rechten heeft op de share en de map.

VPN-login en SMB-login zijn verschillende identiteiten

Een VPN-account wordt door de VPN-gateway volgens zijn eigen beleid beoordeeld. Het beantwoordt de vraag of deze client het privénetwerk binnen mag. Het zegt niets over welk SMB-account bestaat op een bestandsserver binnen dat netwerk.

Een Samba-account staat in de authenticatie-backend van de server, met een eigen wachtwoorddatabase en een eigen naam. Twee machines kunnen allebei een gebruiker met de naam alice hebben zonder een identiteitssysteem, een wachtwoord of een gebruikers-id te delen. De namen komen overeen; de accounts niet.

Een domein-geïntegreerde Samba-server verandert het beeld: de identiteit komt uit de directory en van Kerberos, niet uit een lokale accountlijst. Gebruik in dat geval de directory-identiteit en de ondersteunde SMB-configuratie in plaats van lokale duplicaten te maken om domeinlidmaatschap na te bootsen. Controleer welk model de server gebruikt voordat u een account aanmaakt.

Zie welke identiteit Windows daadwerkelijk gebruikt

Windows cachet verbindingen per server. Als een bestaande sessie naar dezelfde server met een ander account is geopend, kan een nieuwe koppeling die sessie hergebruiken of mislukken met een authenticatiefout die de verkeerde gebruiker noemt. Zo lijkt een correct wachtwoord verkeerd. Inspecteer de huidige verbindingen voordat u inloggegevens wijzigt.

net use
cmdkey /list
klist

Het eerste commando toont gekoppelde schijven en open sessies, het tweede toont opgeslagen inloggegevens die automatisch kunnen worden toegepast, en het derde toont Kerberos-tickets wanneer een domein in gebruik is. Een opgeslagen inloggegeven kan stilzwijgend het account overschrijven dat u wilde invoeren.

Verwijder alleen de verbinding of het inloggegeven dat bij dit probleem hoort. Elke schijf loskoppelen of de servernaam door een IP-adres vervangen verbergt de identiteitskeuze en kan ondertekening of beleid op basis van namen breken.

Koppel de share met het account dat de server erkent

Geef het account op in de vorm die de server verwacht en laat Windows om het wachtwoord vragen, zodat het geheim niet in de commandogeschiedenis of een script terechtkomt:

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

Het serverdeel vóór de backslash is de identiteitscontext van de Samba-server, niet de VPN-gateway. De asterisk vraagt om een interactieve wachtwoordinvoer, en /persistent:no houdt de koppeling buiten de volgende aanmelding. Kies een vrije stationsletter.

Als de server domein-geïntegreerd is, kan het gebruikersdeel in plaats daarvan een directorynaam of een domeingekwalificeerde identiteit zijn. Gebruik de vorm die de beheerder documenteert; een lokaal account met dezelfde naam verzinnen levert een tweede identiteit en een tweede wachtwoord op om te onderhouden.

Accountgeldigheid, sharetoegang en bestandssysteemrechten zijn drie controles

Samba controleert of de identiteit zich authenticeert, of de sharedefinitie haar toelaat, en of het bestandssysteem de gevraagde bewerking toestaat. De eerste controle halen betekent niet dat de andere twee ook slagen. Een share kan zichtbaar zijn en schrijfacties toch weigeren omdat de maprechten dat bepalen.

Een share die met valid users is beperkt, laat alleen de genoemde accounts of groepen toe. Het account kan zich correct authenticeren en toch door die regel worden geweigerd. Controleer de sharedefinitie voordat u concludeert dat het wachtwoord verkeerd is.

Aan de bestandssysteemkant tellen zowel het Samba-proces als de gekoppelde identiteit. Een map die eigendom is van root met modus 700 accepteert geen schrijfacties van een gewoon account, zelfs niet wanneer de sharedefinitie het toestaat. Test met een leesactie en dan een schrijfactie in een map die het account hoort te gebruiken.

Los een conflicterende sessie op zonder het beleid te breken

Wanneer een verouderde sessie de oorzaak is, sluit u die ene verbinding en koppelt u opnieuw met het bedoelde account. Als een opgeslagen inloggegeven blijft terugkomen, verwijdert u dat gegeven in plaats van de hele schijflijst. Bevestig daarna de nieuwe sessie met net use.

Laat de vereiste SMB-ondertekening, versleuteling en accountbeleid staan. Een server die een niet-ondertekende of niet-versleutelde sessie weigert, handhaaft beleid en leest het wachtwoord niet verkeerd; het verzwakken om de koppeling te laten slagen ruilt veiligheid voor een symptoom.

Noteer de servernaam, de exacte accountvorm en de share- en maprechten die werkten. De volgende persoon die de schijf koppelt, probeert anders eerst de VPN-login, omdat dat de inloggegevens zijn waarmee hij het netwerk bereikte.