※ 引述《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 让我重温七年前的问题