※ 引述《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 讓我重溫七年前的問題