Mapado de VPN-dosierkunhavaĵo per la Samba-konto, kiun la servilo konas

Konektu la tunelon, kaj la kunhavaĵo ankoraŭ petas pasvorton, kiun la uzanto kredas ĝusta. En memstara Samba-aranĝo, la VPN-saluto kaj la SMB-saluto estas sendependaj legitimiloj: unu rajtigas la tunelon, la alian kontrolas la dosierservilo. Pro tio mapado de la disko per la VPN-konto malsukcesas eĉ kiam la pasvorto ĝustas kaj la retvojo perfektas. Tiu distingo klarigas la plimulton de mapadaj fiaskoj tra VPN.

La solvo ne estas restarigi la VPN-konton. Ĝi estas nomi identecon, kiun la Samba-servilo vere konas, poste kontroli, ĉu tiu sama identeco havas rajtojn pri la kunhavaĵo kaj la dosierujo.

La VPN-saluto kaj la SMB-saluto estas malsamaj identecoj

VPN-konton taksas la VPN-pordego laŭ sia propra politiko. Ĝi respondas, ĉu ĉi tiu kliento rajtas eniri la privatan reton. Ĝi nenion diras pri tio, kiu SMB-konto ekzistas sur dosierservilo ene de tiu reto.

Samba-konto loĝas en la aŭtentiga malantaŭaĵo de la servilo, kun propra pasvortdatumbazo kaj propra nomo. Du maŝinoj povas ambaŭ havi uzanton nomatan alice sen kunhavigi identecsistemon, pasvorton aŭ uzantidentigilon. La nomoj kongruas; la kontoj ne.

Samba-servilo integrita en domajno ŝanĝas la bildon: la identeco venas el la adresaro kaj el Kerberos, ne el loka kontolisto. En tiu kazo uzu la identecon el la adresaro kaj la subtenatan SMB-agordon anstataŭ krei lokajn duplikatojn por imiti domajnan membrecon. Kontrolu, kiun modelon la servilo uzas, antaŭ ol krei iun ajn konton.

Vidu, kiun identecon Windows efektive uzas

Windows kaŝmemorigas konektojn laŭ servilo. Se ekzistanta sesio al la sama servilo estis malfermita per alia konto, nova mapado povas reuzi tiun sesion aŭ fiaski kun aŭtentiga eraro, kiu nomas la malĝustan uzanton. Tiel ĝusta pasvorto aspektas malĝusta. Kontrolu la nunajn konektojn antaŭ ol ŝanĝi legitimilojn.

net use
cmdkey /list
klist

La unua komando montras mapitajn diskojn kaj malfermitajn sesiojn, la dua montras konservitajn legitimilojn, kiuj povas esti aŭtomate aplikataj, kaj la tria montras Kerberos-biletojn, kiam domajno estas uzata. Konservita legitimilo povas silente anstataŭigi la konton, kiun vi intencis tajpi.

Forigu nur la konekton aŭ legitimilon, kiu rilatas al ĉi tiu problemo. Malkonekti ĉiujn diskojn aŭ anstataŭigi la servilan nomon per IP-adreso kaŝas la elekton de identeco kaj povas rompi subskribon aŭ nom-bazitajn politikojn.

Mapu la kunhavaĵon per la konto, kiun la servilo rekonas

Provizu la konton en la formo, kiun la servilo atendas, kaj lasu Windows peti la pasvorton, por ke la sekreto ne eniru la komandan historion aŭ skripton:

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

La servila parto antaŭ la retroklino estas la identeca kunteksto de la Samba-servilo, ne la VPN-pordego. La stelo petas interagan pasvortpeton, kaj /persistent:no tenas la mapadon ekster la sekva saluto. Elektu liberan diskan literon.

Se la servilo estas domajne integrita, la uzanta parto povas anstataŭe esti adresara nomo aŭ domajne kvalifikita identeco. Uzu la formon dokumentitan de la administranto; elpensi lokan konton kun la sama nomo kreas duan identecon kaj duan pasvorton prizorgendan.

Kontvalideco, aliro al la kunhavaĵo kaj rajtoj de la dosiersistemo estas tri kontroloj

Samba kontrolas, ĉu la identeco aŭtentiĝas, ĉu la difino de la kunhavaĵo akceptas ĝin, kaj ĉu la dosiersistemo donas la petitan operacion. Trapasi la unuan kontrolon ne implicas la aliajn du. Kunhavaĵo povas esti videbla kaj tamen rifuzi skribojn, ĉar la permesoj de la dosierujo tiel diras.

Kunhavaĵo limigita per valid users akceptas nur la listigitajn kontojn aŭ grupojn. La konto povas aŭtentiĝi ĝuste kaj tamen esti rifuzata de tiu linio. Kontrolu la difinon de la kunhavaĵo antaŭ ol konkludi, ke la pasvorto malĝustas.

Ĉe la dosiersistema flanko gravas kaj la Samba-procezo kaj la mapita identeco. Dosierujo posedata de root kun reĝimo 700 ne akceptos skribojn de ordinara konto eĉ kiam la difino de la kunhavaĵo permesas tion. Provu per legado, poste per skribado, en dosierujo, kiun la konto devus uzi.

Purigu konfliktan sesion sen rompi la politikon

Kiam la kaŭzo estas kaduka sesio, fermu tiun unu konekton kaj remapu per la intencita konto. Se konservita legitimilo daŭre revenas, forigu tiun legitimilon anstataŭ la tutan diskan liston. Poste konfirmu la novan sesion per net use.

Konservu la postulatan SMB-subskribon, ĉifradon kaj kontpolitikon. Servilo, kiu rifuzas ne-subskribitan aŭ ne-ĉifritan sesion, plenumas politikon, ne mislegas la pasvorton, kaj malfortigi ĝin por ke la mapado sukcesu interŝanĝas sekurecon kontraŭ simptomo.

Notu la servilan nomon, la ĝustan formon de la konto kaj la rajtojn pri kunhavaĵo kaj dosierujo, kiuj funkciis. Alie la sekva persono, kiu mapos la diskon, unue provos la VPN-saluton, ĉar tiuj estas la legitimiloj, per kiuj ĝi atingis la reton.