แมปแชร์ไฟล์ VPN ด้วยบัญชี Samba ที่เซิร์ฟเวอร์รู้จัก

เชื่อมต่ออุโมงค์แล้วแชร์ยังคงขอรหัสผ่านที่ผู้ใช้คิดว่าถูกต้อง ในการติดตั้ง Samba แบบแยก การเข้าสู่ระบบ VPN และการเข้าสู่ระบบ SMB เป็นข้อมูลรับรองที่ไม่เกี่ยวข้องกัน: ตัวหนึ่งอนุญาตอุโมงค์ อีกตัวถูกตรวจสอบโดยเซิร์ฟเวอร์ไฟล์ ดังนั้นการแมปไดรฟ์ด้วยบัญชี VPN จึงล้มเหลวแม้รหัสผ่านจะถูกต้องและเส้นทางเครือข่ายสมบูรณ์ ความแตกต่างนี้อธิบายความล้มเหลวของการแมปผ่าน VPN ส่วนใหญ่

วิธีแก้ไม่ใช่การรีเซ็ตบัญชี VPN แต่คือการระบุตัวตนที่เซิร์ฟเวอร์ Samba รู้จักจริง แล้วตรวจสอบว่าตัวตนเดียวกันมีสิทธิ์บนแชร์และโฟลเดอร์

การเข้าสู่ระบบ VPN และ SMB เป็นตัวตนที่ต่างกัน

บัญชี VPN ถูกประเมินโดยเกตเวย์ VPN ตามนโยบายของตนเอง มันตอบว่าไคลเอนต์นี้เข้าเครือข่ายส่วนตัวได้หรือไม่ ไม่ได้บอกว่ามีบัญชี SMB ใดอยู่บนเซิร์ฟเวอร์ไฟล์ภายในเครือข่ายนั้น

บัญชี Samba อยู่ในแบ็กเอนด์การรับรองความถูกต้องของเซิร์ฟเวอร์ พร้อมฐานข้อมูลรหัสผ่านและชื่อของตนเอง เครื่องสองเครื่องอาจมีผู้ใช้ชื่อ alice ทั้งคู่โดยไม่แชร์ระบบตัวตน รหัสผ่าน หรือตัวระบุผู้ใช้ ชื่อตรงกัน แต่บัญชีไม่ตรง

เซิร์ฟเวอร์ Samba ที่รวมกับโดเมนเปลี่ยนภาพ: ตัวตนมาจากไดเรกทอรีและ Kerberos ไม่ใช่จากรายการบัญชีภายใน ในกรณีนั้นให้ใช้ตัวตนจากไดเรกทอรีและการกำหนดค่า SMB ที่รองรับ แทนการสร้างสำเนาภายในเพื่อเลียนแบบการเป็นสมาชิกโดเมน ตรวจสอบว่าเซิร์ฟเวอร์ใช้รูปแบบใดก่อนสร้างบัญชีใด ๆ

ดูว่า Windows ใช้ตัวตนใดจริง ๆ

Windows แคชการเชื่อมต่อแยกตามเซิร์ฟเวอร์ หากเซสชันที่มีอยู่ไปยังเซิร์ฟเวอร์เดียวกันถูกเปิดด้วยบัญชีอื่น การแมปใหม่สามารถใช้เซสชันนั้นซ้ำหรือล้มเหลวด้วยข้อผิดพลาดการรับรองที่ระบุผู้ใช้ผิด นี่คือวิธีที่รหัสผ่านที่ถูกต้องดูเหมือนผิด ตรวจสอบการเชื่อมต่อปัจจุบันก่อนเปลี่ยนข้อมูลรับรอง

net use
cmdkey /list
klist

คำสั่งแรกแสดงไดรฟ์ที่แมปและเซสชันที่เปิดอยู่ คำสั่งที่สองแสดงข้อมูลรับรองที่จัดเก็บไว้ซึ่งอาจถูกนำไปใช้โดยอัตโนมัติ และคำสั่งที่สามแสดงตั๋ว Kerberos เมื่อใช้โดเมน ข้อมูลรับรองที่จัดเก็บไว้ อาจเขียนทับบัญชีที่คุณตั้งใจจะพิมพ์อย่างเงียบ ๆ.

ลบเฉพาะการเชื่อมต่อหรือข้อมูลรับรองที่เป็นของปัญหานี้ การตัดการเชื่อมต่อไดรฟ์ทั้งหมดหรือแทนที่ชื่อเซิร์ฟเวอร์ด้วยที่อยู่ IP จะซ่อนการเลือกตัวตนและอาจทำให้การลงนามหรือนโยบายตามชื่อเสีย

แมปแชร์ด้วยบัญชีที่เซิร์ฟเวอร์รู้จัก

ระบุบัญชีในรูปแบบที่เซิร์ฟเวอร์คาดหวัง และให้ Windows ขอรหัสผ่าน เพื่อไม่ให้ความลับไปอยู่ในประวัติคำสั่งหรือสคริปต์:

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

ส่วนเซิร์ฟเวอร์ก่อนแบ็กสแลชคือบริบทตัวตนของเซิร์ฟเวอร์ Samba ไม่ใช่เกตเวย์ VPN เครื่องหมายดอกจันขอพรอมต์รหัสผ่านแบบโต้ตอบ และ /persistent:no เก็บการแมปไว้นอกการลงชื่อเข้าใช้ครั้งถัดไป เลือกตัวอักษรไดรฟ์ที่ว่าง

หากเซิร์ฟเวอร์รวมกับโดเมน ส่วนผู้ใช้อาจเป็นชื่อไดเรกทอรีหรือตัวตนที่ผ่านคุณสมบัติโดเมนแทน ใช้รูปแบบที่ผู้ดูแลระบบจัดทำเอกสารไว้ การคิดค้นบัญชีภายในชื่อเดียวกันจะสร้างตัวตนที่สองและรหัสผ่านที่สองให้ดูแล

ความถูกต้องของบัญชี การเข้าถึงแชร์ และสิทธิ์ของระบบไฟล์เป็นการตรวจสอบสามอย่าง

Samba ตรวจสอบว่าตัวตนรับรองความถูกต้องได้หรือไม่ คำจำกัดความของแชร์ยอมรับหรือไม่ และระบบไฟล์ให้การดำเนินการที่ขอหรือไม่ การผ่านการตรวจสอบแรกไม่ได้หมายความว่าอีกสองอย่างจะผ่าน แชร์อาจมองเห็นได้แต่ยังปฏิเสธการเขียนเพราะสิทธิ์ของโฟลเดอร์บอกเช่นนั้น

แชร์ที่จำกัดด้วย valid users ยอมรับเฉพาะบัญชีหรือกลุ่มที่ระบุไว้ บัญชีอาจรับรองความถูกต้องได้ถูกต้องแต่ยังถูกปฏิเสธโดยบรรทัดนั้น ตรวจสอบคำจำกัดความของแชร์ก่อนสรุปว่ารหัสผ่านผิด

ฝั่งระบบไฟล์ ทั้งกระบวนการ Samba และตัวตนที่แมปมีความสำคัญ โฟลเดอร์ที่เป็นของ root โหมด 700 จะไม่รับการเขียนจากบัญชีธรรมดาแม้คำจำกัดความของแชร์อนุญาต ทดสอบด้วยการอ่านแล้วจึงเขียนในโฟลเดอร์ที่บัญชีควรใช้

ล้างเซสชันที่ขัดแย้งโดยไม่ทำลายนโยบาย

เมื่อสาเหตุคือเซสชันเก่า ให้ปิดการเชื่อมต่อนั้นเพียงหนึ่งรายการแล้วแมปใหม่ด้วยบัญชีที่ตั้งใจ หากข้อมูลรับรองที่จัดเก็บไว้ยังกลับมาซ้ำ ให้ลบข้อมูลรับรองนั้นแทนรายการไดรฟ์ทั้งหมด จากนั้นยืนยันเซสชันใหม่ด้วย net use

รักษาการลงนาม SMB การเข้ารหัส และนโยบายบัญชีที่กำหนดไว้ เซิร์ฟเวอร์ที่ปฏิเสธเซสชันที่ไม่ได้ลงนามหรือไม่ได้เข้ารหัสกำลังบังคับใช้นโยบาย ไม่ได้อ่านรหัสผ่านผิด และการทำให้อ่อนลงเพื่อให้การแมปสำเร็จคือการแลกความปลอดภัยกับอาการ

บันทึกชื่อเซิร์ฟเวอร์ รูปแบบบัญชีที่แน่นอน และสิทธิ์แชร์และโฟลเดอร์ที่ใช้ได้ มิฉะนั้นคนถัดไปที่แมปไดรฟ์จะลองเข้าสู่ระบบ VPN ก่อน เพราะนั่นคือข้อมูลรับรองที่ใช้ไปถึงเครือข่าย