Có thể chuyển tên người dùng và mật khẩu UNC trong đường dẫn UNC không?
Tương tự như cách FTP và SMB hỗ trợ điều này:
smb://user:pass@destination.com/share
ftp://user:pass@destination.com/share
Tôi đang cố gắng để có được quyền truy cập dịch vụ (không phải miền PC) vào đường dẫn DFS.
Có cách nào khác xung quanh điều này? Tôi có thể liên kết PC với miền và chạy dịch vụ với tư cách là người dùng miền nhưng nếu tôi đang sử dụng Linux thì sao?
Câu trả lời:
Trên Windows, bạn không thể đặt thông tin đăng nhập trong đường dẫn UNC. Bạn phải cung cấp cho họ sử dụng net use, runas /netonlyhoặc khi được hỏi bởi Windows. (Nếu bạn có một số kỹ năng lập trình, bạn có thể lưu trữ mật khẩu SMB dưới dạng "thông tin xác thực tên miền" bằng cách sử dụng CredWrite(), tương đương với việc kiểm tra hộp "Ghi nhớ mật khẩu" trong Windows.)
Trên Linux, nó phụ thuộc vào chương trình.
Gvfs của Gnome chấp nhận user@hostcú pháp, nhưng dường như hoàn toàn bỏ qua mật khẩu. (Tuy nhiên, bạn có thể lưu trữ nó trong Khóa Gnome trước đó.)
smbclientsử dụng cú pháp UNC giống như Windows; tuy nhiên, nó có một --authentication-filetùy chọn từ đó thông tin đăng nhập có thể được đọc.
Cả hai chương trình trên đều sử dụng libsmbclient và có thể sử dụng xác thực Kerberos thay vì mật khẩu: chạy kinit user@YOUR.DOMAINvà sử dụng smbclient -k //host/share. Điều này an toàn hơn xác thực mật khẩu.
Lưu ý rằng việc đặt mật khẩu vào URI không được chấp nhận và bạn không nên dựa vào mật khẩu được hỗ trợ ở bất cứ đâu .
Tôi nghĩ rằng tên người dùng và mật khẩu phải được chuyển đến máy chủ để xác thực trước khi có thể thực hiện bất kỳ quyền truy cập tệp nào, vì vậy mã xử lý kết nối SMB phải có khả năng phân tích và thêm tên người dùng và mật khẩu từ URL. Bạn sẽ phải kiểm tra xem mã đó có hỗ trợ định dạng này hay không.
Nếu không, bạn có thể gắn kết chia sẻ SMB đó thông qua SAMBA và hướng dẫn chương trình của bạn sử dụng đường dẫn "cục bộ" đó. Bạn có thể đặt mount vào fstabvà sử dụng tệp mật khẩu SAMBA để cung cấp thông tin đăng nhập của người dùng. Hãy nhớ đặt quyền chính xác cho tệp mật khẩu để người dùng bình thường không thể đọc được.
Lưu ý rằng việc lưu trữ mật khẩu bằng văn bản rõ ràng trong các tệp cấu hình là một thực tế xấu, vì vậy ngay cả khi chương trình của bạn có thể xử lý mật khẩu trong URL, bạn nên xem xét phương pháp chia sẻ được gắn kết.
fstabphải là "tập tin cấu hình văn bản rõ ràng"?
Bạn có thể thêm thông tin đăng nhập trong Bảng điều khiển / Người dùng / Trình quản lý thông tin Windows để thông tin đăng nhập được lưu trữ. Bạn sẽ thêm tên thiết bị (server.domain.local) bằng tên người dùng / mật khẩu tên miền, sau đó bạn sẽ có thể truy cập vào chia sẻ mà không cần cung cấp lại thông tin đăng nhập.
Một PC không có tên miền không thực sự quan tâm đến DFS mà nó không đăng ký hoặc tham gia trực tiếp. Nó chỉ cần xem một đường dẫn chia sẻ (tức là máy chủ / tên tệp). Sharenames xóa tất cả các xem xét đường dẫn máy chủ lưu trữ.
Thành thật mà nói, có nhiều cách an toàn hơn để đăng nhập vào cổ phiếu so với URI UNC. UNC và URI là một giao thức giao tiếp văn bản rõ ràng.
Nếu đó là bảo mật có thể chấp nhận ... tại sao không chỉ có một chia sẻ mở mà không có bất kỳ người dùng hoặc mật khẩu nào?
Giải pháp tức thời đơn giản nhất sẽ là cung cấp cho thông tin đăng nhập dịch vụ quyền truy cập trực tiếp để đăng nhập vào chia sẻ (ví dụ: kết hợp người dùng / mật khẩu). Lâu dài mà không phù hợp rõ ràng có thể làm cho việc nhớ cập nhật quyền bất cứ khi nào mọi thứ thay đổi khó khăn. Và đây cũng là lĩnh vực mà MS có thể thay đổi cách bảo mật vượt qua thông tin xác thực một lần nữa và phá vỡ mọi thứ.
Về lâu dài, điều đơn giản nhất có lẽ là ánh xạ vĩnh viễn một ký tự ổ đĩa cục bộ vào mạng chia sẻ. Bảo vệ ổ đĩa được ánh xạ chỉ có quyền đối với dịch vụ (và quản trị viên phù hợp, v.v.) cộng với tên chia sẻ có thể được ẩn với hàng đầu &.
Nhưng DFS đưa ra manh mối cho một giải pháp thanh lịch hơn. Linux yêu cầu chia sẻ mạng trước tiên phải được gắn kết ... thường là một thư mục trong hệ thống tệp gốc theo cách rất giống với DFS. Lệnh mount Linux cho phép chỉ định tệp thông tin đăng nhập cho tên người dùng và mật khẩu, do đó giúp chúng dễ dàng cập nhật và an toàn hơn so với tập lệnh dòng lệnh hoặc fstab (tức là bảng hệ thống tệp). Tôi khá chắc chắn Windows shell shell và DFS có thể làm điều tương tự (được một thời gian). Nó sẽ chỉ là một hệ thống DFS khác với PC đích để kết hợp các chia sẻ mạng được gắn kết bằng các thông tin lưu trữ được truyền bởi SMB và các dịch vụ đăng nhập thay vì mã hóa cứng trong tập lệnh và được gửi dưới dạng văn bản rõ ràng UNC.
Cũng xem xét nếu PC không tên miền đó sẽ vẫn là một PC không tên miền lâu dài. Máy chủ đăng nhập Kerberos trong * NIX Realms có thể được liên kết với Tên miền Windows AD. Có lẽ những gì bạn muốn làm cho bất kỳ dự án dài hạn nghiêm trọng nào liên quan đến nhiều hơn một vài người. Mặt khác, nó có thể quá mức cần thiết cho hầu hết các tình huống mạng gia đình. Mặc dù nếu bạn đang sử dụng DFS vì bất kỳ lý do chính đáng nào khác ngoài việc tự thử thách sở thích thì có lẽ tốt nhất.
Câu trả lời lưu trữ thông tin đăng nhập của Matt là thanh lịch nhất cho PC Windows hiện đại. Mặc dù không nêu lưu trữ thông tin đăng nhập được sử dụng nên dành cho tài khoản dịch vụ. Đó là cả hai để đảm bảo tính khả dụng cho dịch vụ và do đó, bất kỳ người dùng nào khác mà bạn không muốn truy cập vào chia sẻ đó đều không thể (ví dụ: nhớ thêm để xóa thông tin đăng nhập nhầm trong tài khoản sai).
Nhưng nếu Windows hoặc Linux kế thừa của nó, bạn có thể cần phải mở rộng hơn một chút.
Một PC không có tên miền không thực sự quan tâm đến DFS mà nó không đăng ký hoặc tham gia trực tiếp. Nó chỉ cần xem một đường dẫn chia sẻ (tức là máy chủ / tên tệp). Sharenames xóa tất cả các xem xét đường dẫn máy chủ lưu trữ.
Thành thật mà nói, có nhiều cách an toàn hơn để đăng nhập vào cổ phiếu so với URI UNC. UNC và URI là một giao thức giao tiếp văn bản rõ ràng.
Nếu đó là bảo mật có thể chấp nhận ... tại sao không chỉ có một chia sẻ mở mà không có bất kỳ người dùng hoặc mật khẩu nào?
Giải pháp tức thời đơn giản nhất sẽ là cung cấp cho thông tin đăng nhập dịch vụ quyền truy cập trực tiếp để đăng nhập vào chia sẻ (ví dụ: kết hợp người dùng / mật khẩu). Lâu dài mà không phù hợp rõ ràng có thể làm cho việc nhớ cập nhật quyền bất cứ khi nào mọi thứ thay đổi khó khăn. Và đây cũng là lĩnh vực mà MS có thể thay đổi cách bảo mật vượt qua thông tin xác thực một lần nữa và phá vỡ mọi thứ.
Về lâu dài, điều đơn giản nhất có lẽ là ánh xạ vĩnh viễn một ký tự ổ đĩa cục bộ vào mạng chia sẻ. Bảo vệ ổ đĩa được ánh xạ chỉ có quyền đối với dịch vụ (và quản trị viên phù hợp, v.v.) cộng với tên chia sẻ có thể được ẩn với hàng đầu &.
Nhưng DFS đưa ra manh mối cho một giải pháp thanh lịch hơn. Linux yêu cầu chia sẻ mạng trước tiên phải được gắn kết ... thường là một thư mục trong hệ thống tệp gốc theo cách rất giống với DFS. Lệnh mount Linux cho phép chỉ định tệp thông tin đăng nhập cho tên người dùng và mật khẩu, do đó giúp chúng dễ dàng cập nhật và an toàn hơn so với tập lệnh dòng lệnh hoặc fstab (tức là bảng hệ thống tệp). Tôi khá chắc chắn Windows shell shell và DFS có thể làm điều tương tự (được một thời gian). Nó sẽ chỉ là một hệ thống DFS khác với PC đích để kết hợp các chia sẻ mạng được gắn kết bằng các thông tin lưu trữ được truyền bởi SMB và các dịch vụ đăng nhập thay vì mã hóa cứng trong tập lệnh và được gửi dưới dạng văn bản rõ ràng UNC.
Cũng xem xét nếu PC không tên miền đó sẽ vẫn là một PC không tên miền lâu dài. Máy chủ đăng nhập Kerberos trong * NIX Realms có thể được liên kết với Tên miền Windows AD. Có lẽ những gì bạn muốn làm cho bất kỳ dự án dài hạn nghiêm trọng nào liên quan đến nhiều hơn một vài người. Mặt khác, nó có thể quá mức cần thiết cho hầu hết các tình huống mạng gia đình. Mặc dù nếu bạn đang sử dụng DFS vì bất kỳ lý do chính đáng nào khác ngoài việc tự thử thách sở thích thì có lẽ tốt nhất.