Windows内置安全主体

转自：https://blog.csdn.net/xcntime/article/details/51746148

导读：对于Windows内置安全主体特别需要注意的是：你无法创建、重命名和删除它们，并且它们在任何一个Windows系统中都是一样的。

在上期杂志的“理解Windows内置安全主体（上）”一文中，我们初步了解了Windows内置安全主体（它们是Windows安全子系统中预定义和控制的特殊对象）在管理和维护系统安全方面的强大功能。若仔细阅读了该文，那么你应当了解安全主体在简化和控制Windows资源访问控制上的能力。对于这些Windows内置安全主体特别需要注意的是：你无法创建、重命名和删除它们，并且它们在任何一个Windows系统中都是一样的。在本期文章中，我们将深入了解每个安全主体，为大家展示Windows是如何使用这些内置安全主体，并同时提供一些有用的使用技巧。

Authenticated Users和Everyone
Authenticated Users内置安全主体包括了所有通过Windows用户登录身份验证的用户——包括了域和森林中的所有用户，以及来自其他受信任域森林的用户。
Everyone内置安全主体可以认为是Authenticated Users的父集，它包括了Authenticated Users和Guest帐户。成员关系在不同的环境中稍显复杂。表1中显示了Authenticated Users和Everyone的详细成员关系。从表中可以看出对于Windows XP和Windows 2000的Active Directory（AD），Anonymous帐户默认是Everyone的成员，但不是Authenticated Users的成员。对于Windows Server 2003的AD和Windows XP SP2，Anonymous帐户默认就不是Everyone的成员，但是你可以通过修改Network Access: Let Everyone permissions apply to anonymous users设置，启用这个功能。还可以通过修改注册表HKEY_LOCAL_ MACHINESYSTEMCurrentControlSetControlLSAEveryoneIncludesAnonymous（REG_DWORD）中，键值改为1。无论任何情况下，Anonymous帐户都不会是Authenticated Users的成员
                           

                                                    表1：Authenticated Users和Everyone的成员关系对比

System, Local Service和Network Service
在Windows 2000和更早的版本中，Windows的服务和很多第三方应用程序通常都运行在System内置安全主体的安全上下文环境中（有时也被称为Local System和LSA帐户）。AD用户将其归类为Well-Known-Security-ID-System。System代表了该计算机在网络中的计算机帐户，网络中显示为Domain name machine name$。本地系统的帐户名为NT AUTHORITYSystem。此帐户没有密码，也不需要系统管理员的管理和干预：它自动使用Windows指派的计算机帐户凭据。
System安全主体的威力大抵与UNIX系统中的root帐户类似。当你在System的安全上下文环境中运行服务或者应用程序，那么该服务或应用程序就具备了在这个Windows系统中无所不能的权限。例如，假设一个服务使用System安全主体登录到一台域控制器，那么该服务就成为DC上的本地服务。一旦该服务被黑客攻击利用，那么恶意用户就具有了任何修改AD的权限。所以要特别小心——尤其是遵从最小权限的原则，尽量避免使用System。
为了遵从最小权限原则和避免使用System带来的隐患，Windows Server 2003和Windows XP SP2提供了两种替代方案：Local Service和Network Service。Local Service提供了一般服务在本地运行所需的最小权限。智能卡、远程注册表和Telnet服务都使用Local Service帐户。使用Local Service的服务在访问网络资源时，将默认使用Anonymous凭据。要配置一个服务使用Local Service，打开“服务”控制台，选择所需服务点击右键，“属性”在“登录”对话框中，选择“此帐户”并输入NT AUTHORITYLocalService。无需为此帐户设置密码。
Network Service提供了一般服务在需要访问网络中其它计算机运行所需的最小权限。如同运行System下的服务一样，一个运行在Network Service下的服务在访问网络资源时，需要使用它们的计算机帐户凭据。域名解析服务（DNS）和远程过程调用（RPC）服务都默认使用Network Service。要配置一个服务使用Network Service，打开“服务”控制台，选择所需服务点击右键，“属性”在“登录”对话框中，选择“此帐户”并输入NT AUTHORITYNetworkService。无需为此帐户设置密码。

This Organization和Other Organization
Windows Server 2003中新增了This Organization和Other Organization两个内置安全主体，它们是与一种新的，被称为selective authentication或者authentication 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 Group的功能与Creator Owner十分类似，但并不是在子对象上为Creator Owner添加权限，而是为Creator Group赋予允许或者拒绝的权限。
 Self作为对象的一个占位符。例如，AD管理员在一个OU上将用户对象属性中的postalAddress属性为Self设置了Write权限。当你创建一个称为Jan的用户之后，用户Jan对这个postalAddress属性将具备写的权限（也就是说，Jan可以自行更改用户属性中postalAddress地址的权力）。注意在其他用户对象上相同的Self权限，Jan将无法更改其他用户的postalAddress属性，因为Self仅仅针对其自身的用户帐户。
默认情况下，Windows为Self赋予组成员关系Read的权限。这个设置保证了每个组成员都可以查看他们所在的组还有其他成员。由于AD还赋予了Authenticated Users对组成员列表读的权限，所以Authenticated Users也可以看到相同的内容。

功能强大但是稍显复杂
至此，你大概已经了解了Windows内置安全主体具备的强大功能，对Windows如何进行访问控制更加加深了一些理解。看看Windows Server 2003中新增的内置安全主体，以及权限委派、自我管理的应用越来越普及，可以想象将来的Windows还将添加更多的内置安全主体。