※ 引述《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/cn.aspx?n=bbs/Windows/M.1607518538.A.982.html ※ 编辑: JohnThunder (122.146.90.205 台湾), 12/09/2020 21:00:53