Pag-map ng VPN file share gamit ang Samba account na kilala ng server

Ikonekta ang tunnel at humihingi pa rin ang share ng password na sa tingin ng user ay tama. Sa standalone na deployment ng Samba, ang VPN login at SMB login ay magkaibang kredensyal: isa ang nagpapahintulot sa tunnel, ang isa ay sinusuri ng file server. Kaya nabigo ang pag-map ng drive gamit ang VPN account kahit tama ang password at perpekto ang network path. Ang pagkakaibang ito ang nagpapaliwanag sa karamihan ng kabiguan sa pag-map sa VPN.

Hindi ang pag-reset ng VPN account ang solusyon. Ang solusyon ay pangalanan ang identity na talagang kilala ng Samba server, at pagkatapos ay tiyakin na ang parehong identity ay may karapatan sa share at sa direktoryo.

Magkaibang identity ang VPN login at SMB login

Ang VPN account ay sinusuri ng VPN gateway ayon sa sarili nitong patakaran. Sinasagot nito kung ang client na ito ay puwedeng pumasok sa pribadong network. Wala itong sinasabi tungkol sa kung aling SMB account ang umiiral sa file server sa loob ng network na iyon.

Ang Samba account ay naninirahan sa authentication backend ng server, may sariling password database at sariling pangalan. Maaaring parehong may user na alice ang dalawang machine nang hindi nagbabahagi ng identity system, password o user identifier. Pareho ang pangalan; hindi ang account.

Binabago ng Samba server na pinagsama sa domain ang larawan: ang identity ay galing sa direktoryo at sa Kerberos, hindi sa lokal na listahan ng account. Sa ganoong kaso gamitin ang identity mula sa direktoryo at ang sinusuportahang SMB configuration sa halip na gumawa ng lokal na kopya para gayahin ang pagiging miyembro ng domain. Suriin kung aling modelo ang ginagamit ng server bago gumawa ng anumang account.

Tingnan kung aling identity ang talagang ginagamit ng Windows

Ini-cache ng Windows ang mga koneksyon bawat server. Kung ang umiiral na session sa parehong server ay binuksan gamit ang ibang account, maaaring muling gamitin ng bagong pag-map ang session na iyon o mabigo ito sa authentication error na tumutukoy sa maling user. Ganoon lumilitaw na mali ang tamang password. Suriin ang kasalukuyang koneksyon bago baguhin ang kredensyal.

net use
cmdkey /list
klist

Ipinapakita ng unang command ang mga naka-map na drive at bukas na session, ng pangalawa ang mga naka-save na kredensyal na maaaring awtomatikong mailapat, at ng pangatlo ang mga Kerberos ticket kapag may domain na ginagamit. Ang naka-save na kredensyal ay maaaring tahimik na palitan ang account na balak mong i-type.

Alisin lamang ang koneksyon o kredensyal na kabilang sa problemang ito. Ang pagdiskonekta sa lahat ng drive o pagpapalit ng pangalan ng server ng IP address ay nagtatago ng pagpili ng identity at maaaring makasira ng signing o patakarang nakabatay sa pangalan.

I-map ang share gamit ang account na kinikilala ng server

Ibigay ang account sa anyong inaasahan ng server at hayaang tanungin ng Windows ang password, para hindi mapunta ang sikreto sa history ng command o sa isang script:

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

Ang bahagi ng server bago ang backslash ay ang identity context ng Samba server, hindi ang VPN gateway. Ang asterisk ay humihingi ng interactive na password prompt, at pinapanatili ng /persistent:no ang pag-map sa labas ng susunod na sign in. Pumili ng libreng titik ng drive.

Kung ang server ay pinagsama sa domain, ang bahagi ng user ay maaaring pangalan ng direktoryo o identity na kwalipikado sa domain. Gamitin ang anyong dokumentado ng administrator; ang pag-imbento ng lokal na account na may parehong pangalan ay gumagawa ng pangalawang identity at pangalawang password na dapat alagaan.

Ang bisa ng account, access sa share at mga karapatan sa file system ay tatlong pagsusuri

Sinusuri ng Samba kung nagpapatunay ang identity, kung tinatanggap ito ng depinisyon ng share, at kung ibinibigay ng file system ang hinihinging operasyon. Ang pagpasa sa unang pagsusuri ay hindi nangangahulugang pasado rin ang dalawa pa. Maaaring nakikita ang share ngunit tumatanggi sa pagsulat dahil ganoon ang sinasabi ng mga permiso ng direktoryo.

Ang share na nilimitahan ng valid users ay tumatanggap lamang ng mga account o grupong nakalista. Maaaring magpatunay nang tama ang account at tanggihan pa rin ng linyang iyon. Suriin ang depinisyon ng share bago magpasya na mali ang password.

Sa panig ng file system, mahalaga ang prosesong Samba at ang naka-map na identity. Ang direktoryong pag-aari ng root na may mode 700 ay hindi tatanggap ng pagsulat mula sa ordinaryong account kahit pinapayagan ito ng depinisyon ng share. Subukan sa pagbasa, pagkatapos sa pagsulat, sa direktoryong dapat gamitin ng account.

Linisin ang salungat na session nang hindi lumalabag sa patakaran

Kapag ang dahilan ay lumang session, isara ang isang koneksyong iyon at i-map muli gamit ang nilalayong account. Kung paulit-ulit na bumabalik ang naka-save na kredensyal, alisin ang kredensyal na iyon sa halip na ang buong listahan ng drive. Pagkatapos ay kumpirmahin ang bagong session gamit ang net use.

Panatilihin ang kinakailangang SMB signing, encryption at patakaran ng account. Ang server na tumatanggi sa session na walang lagda o walang encryption ay nagpapatupad ng patakaran, hindi nagbabasa ng maling password, at ang pagpapahina nito para magtagumpay ang pag-map ay nakikipagpalit ng seguridad sa isang sintomas.

Itala ang pangalan ng server, ang eksaktong anyo ng account at ang mga karapatan sa share at direktoryo na gumana. Kung hindi, susubukan muna ng susunod na mag-map ng drive ang VPN login, dahil iyon ang kredensyal na ginamit niya para makarating sa network.