※ 引述《JohnThunder (JohnThunder)》之銘言： : 如標題 : 現在自己架設了一台AD，想說開Share分享檔案。 : A_F、B_F、C_F 三個資料夾 : 設定A、B、C能讀取自己的資料夾， : 對別人完全不能讀取。 : 權限設定沒問題 : 假設domain name = example.org : 環境1:網路芳鄰連接\\example.org\ : 可以切入非自己群組的資料夾 : 但是看不到東西和無法寫入。 : 環境2:連結\\example.org.\ : 多了一個.之後， : 對非自己群組的就不能切入資料夾， : 也就無法寫入讀取。 : 當然直接打IP的話就跟環境2一樣 : Q1:請問多了那一個"."，那個作用是甚麼? : Q2:資料夾總共總共有3個地方可以設定權限，取得權限的順序是? : 懇請各位知道的人解惑 沒想到七年前的自己問了一個這樣的問題， 七年後的我心血來潮來做回覆，同時也是想把這個解答留在 PTT 上 以供以後的人能夠查到，讓知識不被資訊黑洞吸走。 以下是回答的問題 Q1:請問多了那一個"."，那個作用是甚麼? A1: 首先要知道當我們使用 \\example.org\ 連線網路共用檔案 的時候，使用 FQDN 在 AD 環境中的 Windows 預設會走了 kerberos 為驗證 方式 而多了一個 "." ，連線 \\example.org.\ 的時候，也會走 kerberos，而後面加入 "." 在 TGS 階段會得到 error-code: KRB5KDC-ERR-S-PRINCIPAL-UNKNOWN (7)，而這個訊息則是代表找不到 PRINCIPAL Name。 所以做了一個簡單的實驗，錄下網路封包我們可以觀察到，TGS 失敗後 Windows client 從 kerberos 驗證 downgrade 成 NTLM 驗證 https://i.imgur.com/7i2UhTv.png 對於這段 Server Principal Lookup 流程感興趣的可以看微軟文件: https://reurl.cc/bRp1Al 而 DNS 正規格式本來就是要 "."結尾的，但結尾不輸入 "." 也是可以解析成功， 所以 example.org. 這個 domain name 是可以正常被解析出 IP ，才導致問題敘述中跟輸入 IP 的狀況一模一樣。 簡而言之，多了那一個 "." 從 kerberos 改走 NTLM 驗證， DNS 能夠成功解析帶有 "."結尾的 domain 所以導致連線看起來一切正常。 Q2: 資料夾總共總共有3個地方可以設定權限，取得權限的順序是? A2: 這讓我通靈了一下，當初的我到底在問哪三個地方的設定。 最後總算整理出來三個地方，這三個地方都在目錄右鍵內容中，以下以英文版 win10 為描述: 1. Sharing Tab 中 share 按鈕，在此設定的權限會修改到 Share & NTFS Permissions 2. Sharing Tab 中 Advanced Sharing ，在此設定的權限只會套用到 Share Permissions 3. Security Tab 的權限設定則為 NTFS Permissions 簡短歸納一下，主要分享需要注意兩個權限 Share Permissions & NTFS Permissions ，詳細說明和如何正確設定權限可以參考微軟文件。 https://reurl.cc/N6ez9n 幫七年前的我補充的第三個問題 Q3: 為甚麼加入 "." 會有權限的不同 A3: 這其實有點通靈，但應該牽涉到 Q1 的問題，只能推論當年測試的環境在連線 NTLM 的 file server 登入的身分是其他的帳號。 因為牽扯到 windows 系統的權限設計，我覺得不可能同一組 SID 有兩種不同結果。 雖然上面回答問題比較簡單，但背後可以追的內容其實很多，例如: Microsoft AD kerberos 驗證中帶的各種欄位、Windows 權限設定與 file server 應該如何正確的做 權限設定... 感謝 PTT 讓我重溫七年前的問題 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.146.90.205 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Windows/M.1607518538.A.982.html ※ 編輯: JohnThunder (122.146.90.205 臺灣), 12/09/2020 21:00:53