设为首页 加入收藏

TOP

Windows内置安全主体(二)
2019-08-24 00:10:27 】 浏览:104
Tags:Windows 内置 安全 主体
firewall的域森林间信任关系而出现的。Selective authentication允许你定义一个额外的访问控制层,从而实现跨森林间的资源访问控制。例如,你可以使用selective authentication限制几台计算机的登录,之后在那台计算机上再允许或者拒绝访问对象。
你可以为域森林信任关系或者外部域森林间信任关系配置selective authentication。你可以为两个域森林的根域创建信任关系,将其应用到森林之间的资源访问控制。也可以为两个域森林中任意两个域之间创建信任关系,将其应用到森林之间的资源访问。
通过“AD域和信任关系”控制台中的“新建信任向导”或者信任关系的属性页来配置一个森林或者外部信任关系为selective authentication。要配置selective authentication,在信任关系“属性”对话框的“验证”中选择selective authentication。
需要注意,只有当你的Windows Server 2003域运行在纯模式状态,并且森林中的域定义了向外的信任关系之后才能够选择设定selective authentication。此外,你也可以为一个Windows NT 4.0域配置selective authentication,用以限制它对另一个Windows Server 2003域中资源的访问控制。
当一个域森林或者外部信任关系被设置为selective authentication,若有用户尝试访问外部被信任域的资源时(通过跨森林的信任关系),Windows会在该用户的访问令牌中加入Other Organization内置安全主体。所有在域森林内跨域访问资源的用户,在其访问令牌中默认都持有The Organization的内置安全主体标识。当有用户访问外部被信任域的资源(通过跨森林的信任关系),而此信任关系没有被配置为selective authentication,那么Windows则将This Organization安全主体添加到该用户访问令牌中。在这种情况下,This Organization的成员就与Authenticated Users的成员一样了。
若一位用户的访问令牌中包括Other Organization内置安全主体,资源服务器会检查该用户的访问权限是否在资源服务器的Allowed-to-Authenticate中被允许。你可以在计算机对象的ACLs中修改Allowed-to-Authenticate权限。如果该用户具备Allowed-to-Authenticate中的权限,那么跨森林的验证成功。在验证阶段,资源服务器将检测是否为Other Organization赋予了的权限,并以此决定允许或者拒绝对资源的访问。

Restricted Code
Windows新增的Restricted Code内置安全主体,在Windows Server 2003中当用户使用带Run this program with restricted access选项的RunAs命令和在Windows XP中使用带Protect my computer and data from unauthorized program activity选项的RunAs命令时,系统将把该安全主体加入到用户访问令牌中。RunAs命令为广大系统管理员提供了非常便利的条件,在普通用户帐户的安全上下文中,使用该命令方便的切换至只有系统管理员才有权限运行的各种管理程序,这样能够有效防止恶意程序滥用管理员权限,而且遵循了最小权限原则。要了解更多关于RunAs命令的信息,请参阅文章“Learn to Be Least”(2005年10月,InstantDoc ID 47622)。
当用户访问令牌中包括Restricted Code内置安全主体,Windows会忽略该用户除了Bypass Traverse Checking之外的所有权限设置,防止应用程序访问用户的配置文件,对注册表区域HKEY_LOCAL_ MACHINE和HKEY_CURRENT_ USER仅有读的权限。
Restricted Code安全主体为遵从最小权限配置和使用单一用户名密码提供了非常便利的条件。要了解更多关于RunAs命令的功能以及如何结合使用Restricted Code安全主体的知识,建议阅读Aaron Margosis的Blog文章“Running Restricted”(http://blogs.msdn.com/aaron_ margosis/archive/2004/09/10/227727.aspx)。

Logon-和Authentication-Type
在Windows Server 2003、Windows XP和Windows 2000的操作系统中,Windows还会根据登录方式在访问令牌中加入相应的内置安全主体。其中Logon-Type安全主体包括Batch、Dialup、Interactive、Network、Service和Terminal Server User(Terminal Server User是指所有使用终端服务4.0兼容应用程序登录的用户)。
Windows Server 2003和Windows XP SP2中还增加了Remote Interactive Logon内置安全主体,它代表所有使用Windows Server 2003或者Windows XP版本的终端服务或者远程桌面登录的用户。要了解更多关于登录类型的信息,请参阅本刊2005年9月刊文章“登录权限:Windows访问控制的核心”。
Windows Server 2003还增加了三个与验证协议有关的内置安全主体——NTLM Authentication、SChannel Authentication和Digest Authentication。这三个内置安全主体分别对应了用户在登录Windows时所采用的身份验证协议。值得注意的是,微软没有为Kerberos和基本身份验证提供相应的安全主体。
你可以利用登录和身份验证类型的内置安全主体,对用户和资源进行更加细致的颗粒级访问控制。这些新的内置安全主体赋予了你根据用户采用的身份验证协议(例如:NTLM,Digest,SSL)和登录类型(例如:通过控制台、使用终端服务等),为不同类型的用户配置不同级别的访问权限。

Self,Creator Owner和Creator Group
在Windows系统中运用了很多层次结构的概念(包括AD,注册表以及文件系统),并且它们都支持用户权限的继承关系。当你为父对象定义了一种权限,那么该权限将自动应用到父对象中的所有子对象上。实现这种功能的原理就在于:Windows利用了Self、Creator Owner和Creator Group这几个内置安全主体。
一般而言,当你将这三个内置安全主体加入父对象的ACL中后,其中的子对象将通过以下几种方式继承这些安全主体:
? 对于父对象上Creator Owner安全主体具备的权限,在新创建的子对象上这些权限将被自动继承。例如,AD管理员在一个OU上为Creator Owner设置了Write的权限,那么当一个用户在该OU中创建一个新用户之后,该用户对于此新建的对象就天然具备Write的权限。
? Creator Gr

首页 上一页 1 2 3 下一页 尾页 2/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇今年开搞了,搭建一下vue开发环境 下一篇Postman 安装

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目