回头去看上一篇日志,流水账一样,看得人发昏。
简单来说就4件事:
硬盘对拷源盘和目标盘弄反导致数据丢失,安装SQL Server 2005未事先查清需要的先决条件,过度滥用重装系统浪费时间还解决不了问题,表达不严谨引起误会。
抛开公司不严谨的流程和规定,技术不成熟和盲目冒进是必须吸取的教训。
本周是NTFS权限的问题
一个部门的文件夹访问权限丢失。
NTFS继承、阻止继承还有强制夺取所有者对原来权限的影响还需要实验验证。
一、父对象权限的变化如何影响已经明确取消继承的子对象权限
a对父对象有适当权限的用户强制子对象继承权限会覆盖掉子对象明确定义过的权限
b)子对象手动勾选继承父对象权限不会清除子对象已经明确定义过的权限
c)父对象权限的变化不会影响已经取消继承子对象的权限
二、如何确保新账号的权限应用到所有的子对象
强制子对象继承,但会清除子对象原有的权限
三、强制下推权限和原有的权限的影响是叠加还是覆盖
覆盖
四、所有者的改变对权限的影响
a)原有的所有者手动更改所有者不会改变权限
b)强制夺取所有者不会改变权限,但是强制夺取所有者的目的在于改变权限
五、如何限制域中能够夺取所有者的成员
组策略:计算机配置 安全设置 本地策略 用户权限分配 取得文件或其他对象的所有权
ceater owner拥有的权限是仅子文件夹和文件的完全控制权限
某一用户组不显示任何权限是对当前对象没有权限而对其子对象有权限
共享和NTFS最严格的权限是最终非本地访问的权限,共享做不到严格,一个共享就只至少要打开domain usre或者autheticated user写的权限
实验搞清楚上面的问题后就可以一步步出自己的操作造成的影响:
用户打开文件access deny->检查用户所在组对文件所在的文件夹权限列表为空:被用户自己修改过。文件夹默认会继承上层folder的权限。如果用户所在组没有上层folder的权限这里不会出现用户所在的组(用户如果想自己加它进来必定会给读或写的权限)而create owner只会是人而不会是组。用户应该是不想别人看到他建的文件夹而尝试修改权限但修改过程中出错了。
尝试给用户加文件夹的权限->域管理员没有文件夹父对象的任何权限->文件夹继承而来的权限就没有domain admin的权限->继续往上层目录走->domain admin有full的权限->
尝试下推->覆盖掉子对象明确定义过的权限->导致权限最大化,用户所在组所有人看到文件夹下所有子对象内容
这件事情两个原因,一个不仔细看系统弹框,英文的系统内容多术语复杂引起的吧;第二是对ntfs权限了解得不够深入
吸取的教训是:权限最大化了
这件事情也很清楚了,用户以create owner的身份误操作引起的权限错误