共享权限ACL列表出现SID现象
2013-07-26 16:09
246 查看
http://www.minasi.com/forum/topic.asp?TOPIC_ID=16842
Basically here's what happens, and why it doesn't get cleaned up. Apologies if some of this is too basic.
1) Accounts and SIDS in a domain: typically you create a user account or a group not locally but on a domain controller. Every user account has a number of characteristics, but the two we're interested in here are:
SID -- Security ID, a UNIQUE identifier for a user account. Looks like S-1-5-21-8989239-232787-1321897-1079 or something like that. The S-1-5-21 shows up on all user accounts, the three big numbers following that are common for all SIDs in a given domain, and the final number (1077) is the only thing about YOUR SID that is different from everyone ELSE's SIDS in the domain.
The important part is that THIS is your true name on the domain.
Friendly Name -- the Microsoft word for what you call yourself. So while I might think that my account name is "mminasi," and if I log in as "mminasi," as far as Windows cares this is nothing more than window dressing, a mildly interesting characteristic about me, like my height, weight, eye color or the like.
2) Permissions:
Permissions are created and stored on the object that they refer to. So, for example, let's say that I've got a DC named DC1 and a member server called MS1. Suppose further that I create a share called STUFF on MS1, and a global group on the domain called COOLGUYS. I want only COOLGUYS to be able to access \\ms1\stuff.
So I go to the MS1 server and tell it either via GUI, NET SHARE or whatever to create an access control entry that says "the global group COOLGUYS has Full Control of the STUFF share."
Let's review what's happened under the hood.
COOLGUYS: this is a thing that lives on DC1, as it's a domain group. It has, let us say, a SID of S-1-5-21-8989239-232787-1321897-1115 and, of course, a friendly name of COOLGUYS.
STUFF share: lives on MS1. Sitting somewhere on MS1 is a piece of information called an "access control entry" or ACE saying "the account with SID S-1-5-21-8989239-232787-1321897-1115 has full control of the STUFF share."
Notice two things there. First, DC1 knows NOTHING about the share. Data on that share, including its permissions, are all stored locally on the member server. Second, the information on MS1 DOES NOT CONTAIN THE FRIENDLY NAME OF COOLGUYS. All it remembers is the SID.
So now let's suppose you decide to fire up Explorer while sitting at MS1 and take a look at the permissions on share STUFF. What happens? MS1 says "dang, that user person wants to see the share permissions, but I'm not supposed to show him that SID thing. Gotta look up the friendly name, so I'll open hailing frequencies to DC1 and ask him... ah, he tells me that it's 'COOLGUYS,' so I'll report that."
But what if DC1 doesn't respond? Then MS1 just shows you the SID next to an empty user head (no jokes here please<g>) with a question mark in the head. Sometimes you will see that change to a normal head and a friendly name before your very eyes, if the network clears up and the member server finally gets the friendly name.
Let's keep "but"-ing...
What if you, the domain admin, delete the COOLGUYS group? Then the object's gone from DC1. Does DC1 give MS1 a heads-up on this? Nope, it can't... remember, the domain basically doesn't know anything about the share, so it couldn't if wanted to. (Yes, you can publish a share in AD but that doesn't change things.)
So now what happens when you go to look at the permissions on \\MS1\STUFF? Simple: MS1 asks DC1 for S-1-5-21-8989239-232787-1321897-1115's friendly name, and never gets an answer. Result: empty heads.
Subinacl will optionally do a friendly name lookup for every ACE on a system, and delete any ACEs that cannot produce a friendly name. Clearly you should only do this when the connectivity to the DC is good!<g>
Again, sorry if some of that was basic but I hope it helped someone.
Basically here's what happens, and why it doesn't get cleaned up. Apologies if some of this is too basic.
1) Accounts and SIDS in a domain: typically you create a user account or a group not locally but on a domain controller. Every user account has a number of characteristics, but the two we're interested in here are:
SID -- Security ID, a UNIQUE identifier for a user account. Looks like S-1-5-21-8989239-232787-1321897-1079 or something like that. The S-1-5-21 shows up on all user accounts, the three big numbers following that are common for all SIDs in a given domain, and the final number (1077) is the only thing about YOUR SID that is different from everyone ELSE's SIDS in the domain.
The important part is that THIS is your true name on the domain.
Friendly Name -- the Microsoft word for what you call yourself. So while I might think that my account name is "mminasi," and if I log in as "mminasi," as far as Windows cares this is nothing more than window dressing, a mildly interesting characteristic about me, like my height, weight, eye color or the like.
2) Permissions:
Permissions are created and stored on the object that they refer to. So, for example, let's say that I've got a DC named DC1 and a member server called MS1. Suppose further that I create a share called STUFF on MS1, and a global group on the domain called COOLGUYS. I want only COOLGUYS to be able to access \\ms1\stuff.
So I go to the MS1 server and tell it either via GUI, NET SHARE or whatever to create an access control entry that says "the global group COOLGUYS has Full Control of the STUFF share."
Let's review what's happened under the hood.
COOLGUYS: this is a thing that lives on DC1, as it's a domain group. It has, let us say, a SID of S-1-5-21-8989239-232787-1321897-1115 and, of course, a friendly name of COOLGUYS.
STUFF share: lives on MS1. Sitting somewhere on MS1 is a piece of information called an "access control entry" or ACE saying "the account with SID S-1-5-21-8989239-232787-1321897-1115 has full control of the STUFF share."
Notice two things there. First, DC1 knows NOTHING about the share. Data on that share, including its permissions, are all stored locally on the member server. Second, the information on MS1 DOES NOT CONTAIN THE FRIENDLY NAME OF COOLGUYS. All it remembers is the SID.
So now let's suppose you decide to fire up Explorer while sitting at MS1 and take a look at the permissions on share STUFF. What happens? MS1 says "dang, that user person wants to see the share permissions, but I'm not supposed to show him that SID thing. Gotta look up the friendly name, so I'll open hailing frequencies to DC1 and ask him... ah, he tells me that it's 'COOLGUYS,' so I'll report that."
But what if DC1 doesn't respond? Then MS1 just shows you the SID next to an empty user head (no jokes here please<g>) with a question mark in the head. Sometimes you will see that change to a normal head and a friendly name before your very eyes, if the network clears up and the member server finally gets the friendly name.
Let's keep "but"-ing...
What if you, the domain admin, delete the COOLGUYS group? Then the object's gone from DC1. Does DC1 give MS1 a heads-up on this? Nope, it can't... remember, the domain basically doesn't know anything about the share, so it couldn't if wanted to. (Yes, you can publish a share in AD but that doesn't change things.)
So now what happens when you go to look at the permissions on \\MS1\STUFF? Simple: MS1 asks DC1 for S-1-5-21-8989239-232787-1321897-1115's friendly name, and never gets an answer. Result: empty heads.
Subinacl will optionally do a friendly name lookup for every ACE on a system, and delete any ACEs that cannot produce a friendly name. Clearly you should only do this when the connectivity to the DC is good!<g>
Again, sorry if some of that was basic but I hope it helped someone.
相关文章推荐
- ACL权限控制列表
- 您不具备查看该目录或页面的权限,因为访问控制列表 (ACL) 对Web服务器上的该资源进行了配置
- acl权限列表
- 《初入linux》--第十二部分-ACL用户权限列表权限
- oracle 11g 发信需要赋予权限 ORA-24247: 网络访问被访问控制列表 (ACL) 拒绝
- 列表中循环添加字典出现覆盖现象的问题
- 灵活使用ACL设置samba的共享权限(user1可读写,user2可读不可写,user3可写不可读,user4只能看到共享!)
- [11月31日的脚本] 从文件/文件夹的访问控制列表(ACL)移除孤立的SID (PowerShell)
- windows网络共享访问centos samba服务端出现权限问题不能访问解决
- 您不具备查看该目录或页面的权限,因为访问控制列表(ACL)对Web 服务器上的该资源进行了配置或者访问网站时出现登录对话框。
- icacls备份与还原ACL列表(NTFS权限)--Robocopy
- 4000 文件用户组及权限的更改,acl列表,mask值
- 域里共享主机对应 打印机 出现权限问题~
- centos 的权限管理--自主访问控制DAC和访问控制列表 ACL
- Win7电脑开启局域网连接和共享过程中出现的"您可能没有权限使用网络资源"的解决办法
- 文件权限的管理以及acl权限列表
- 双网卡实现共享上网时出现时断时续现象的解决办法
- Linux基础(四)文件权限、acl 权限列表
- acl权限列表
- 服务器共享文件夹后,客户端出现“您可能没有权限使用网络资源”提示的解决办法