AGDLP
AGDLP是account, global, domain local, permission的缩写，简单帮助了微软针对在原生模式活动目录（AD）中使用嵌套群组（nested group）实现以角色为基础的访问控制（RBAC）时，相关的建议：用户和电脑账号（accounts）依其在企业中的角色，划分为对应全局（global）群组的成员，全局群组是网域区域组群（domain local groups）的成员，网域区域组群帮助资源访问许可（permissions）或是用户权限设置。AGUDLP（对应account, global, universal, domain local, permission）和 AGLP（对应account, global, local, permission）也是活动目录和Windows Server网域中类似的RBAC实现方式。
细节
编辑以角色为基础的访问控制（RBAC）简化了重复性账号管理流程，也有助于信息安全审核[1]。系统管理者不会直接针对个别用户指定访问权限。系统管理者会依其在企业中的角色来指定访问权限，因此在创建、修改或删除用户权限时，可以不用去维护一份可能很大（而且常常变更的）资源许可及用户权限设置。以角色为基础的访问控制（RBAC）和传统的访问控制表不同，RBAC的许可不是列出细节的各文件访问方式，而是在特定应用或是系统内有意义的操作。将角色和许可存储在集中式的数据库或目录服务中，简化了确定和控制各角色成员以及各角色访问许可的流程[2]。审核可以在一个地方分析访问许可的指定方式，不用去了解特定访问层级下，针对各资源的实现细节。
单一AD网域中的RBAC
编辑微软实现RBAC的方式利用了活动目录中不同的安全组群[3][4]：
- 全局安全组群（Global security groups）
- 全局范围的网域安全组群代表在企业中的角色，或是在此网域中的功能。这些组群可以包括个别账号，同一网域内的其他全局组群，也可以用在网域森林中的资源里。这些组群可以经常变更，不会有全局目录复制的问题。
- 网域区域安全组群（Domain local security groups）
- 网域区域范围的网域安全组群帮助细节的访问权限或是用户权限。只有同一个网域的系统可以用到这些组群。网域安全组群可以包括账号、全局组群、以及任何网域的万用组群（universal groups），也可以包括同一个网域的其他网域区域组群。
表示企业中功能的全局安全组群应该只有用户或电脑账号。表示资源访问许可或是其他用户权限的网域区域组群，其中应该只有全局安全组群，没有个别账号。不应该对账号或是企业角色直接设置访问许可或是用户权限，这样才能简化访问权限的分析。
Active Directary森林中的RBAC
编辑Active Directary森林是指多个网域的环境，各个网域可能是透过广域网或虚拟专用网连接，会有称为全局目录服务器（global catalog server）的网域控制器会缓存目录对象对象以及属性类型，以减少跨网域缓慢的目录查询[5]。全局目录服务器缓存的对象包括了万用组群（universal group），不包括全局组群（global group），使得万用组群的成员查询比全局组群的查询要快很多。不过万用组群的任何修改都会触发全局的目录复制（而且可能成本很高），在万用组群的修改需要Active Directary森林层级的的安全权限，这在大部分的大型企业不太适用。因为这二个限制，让万用安全组群没有完全取代全局安全组群来表示在成员在企业中的角色。在此环境下，用万用安全组群来表示在公司内的角色，但又维持各网域个别的全局安全组群，就简称为AGUDLP。
在非AD网域下的RBAC
编辑在Windows NT 4.0或较早版本的网域只有全局（网域等级）及区域（非网域层级）的组群，在网域等级不支持嵌套群组[6]。缩写AGLP是指这种在较早期网域的RBAC实现：全局（Global）组群表示企业角色，而区域（local）组群（在网域成员数据库中）帮助各用户的权限。
例子
编辑假设一个共享文件夹， \\nyc-ex-svr-01\groups\bizdev; 是公司营销部门的业务发展组，在活动目录中是在（已有的）全局安全组群“业务开发团队成员”以下，有要求这整个组群都要可以读写共享文件夹，管理者若依AGDLP，其访问控制方式如下：
- 在活动目录创建新的网域全局安全组群，名称为“允许修改\\nyc-ex-svr-01\groups\bizdev”。
- 在bizdev文件夹中，对这个网域全局组群给予NTFS "change"的权限集（read, write, execute/modify, delete）（注意，安全描述符和共享许可是不同的）。
- 让全局组群“业务开发团队成员”成为网域区域安全组群“允许修改\\nyc-ex-svr-01\groups\bizdev”的成员。
为了要突显使用RBAC控管权限的好处，若业务发展组需要bizdev额外的权限，系统管理者只需要编辑单一的访问控件（access control entry），不用编辑其中每一个成员的访问控件。
参考资料
编辑- ^ Ferraiolo, D.F.; Kuhn, D.R. Role Based Access Control (PDF). 15th National Computer Security Conference: 554–563. October 1992 [2021-10-20]. （原始内容 (PDF)存档于2011-06-05）.
- ^ Sandhu, R.; Coyne, E.J.; Feinstein, H.L.; Youman, C.E. Role-Based Access Control Models (PDF). IEEE Computer. August 1996, 29 (2): 38–47 [2021-10-20]. CiteSeerX 10.1.1.50.7649
. doi:10.1109/2.485845. （原始内容 (PDF)存档于2011-06-05）.
- ^ Microsoft Corporation. Group Scopes: Active Directory. Microsoft Technet. 2007-03-16 [2009-04-28]. （原始内容存档于14 March 2009）.
- ^ Melber, Derek. How to Nest Users and Groups for Permissions. WindowsSecurity.com. 2006-05-18 [2009-04-28]. （原始内容存档于2013-01-17）.
- ^ Microsoft Corporation. Understanding the Global Catalog: Active Directory. Microsoft Technet. 2005-01-21 [2005-10-21]. （原始内容存档于2016-03-05）.
- ^ Stanek, William R. Understanding User and Group Accounts. Microsoft Technet. [2009-04-28]. （原始内容存档于27 April 2009）.
