![将某些 Active Directory 帐户标识为“IsHuman”](https://linux22.com/image/682663/%E5%B0%86%E6%9F%90%E4%BA%9B%20Active%20Directory%20%E5%B8%90%E6%88%B7%E6%A0%87%E8%AF%86%E4%B8%BA%E2%80%9CIsHuman%E2%80%9D.png)
我想标记某些 Active Directory 帐户以表明它们代表个人、自然人,而不是组、服务帐户、内置帐户等。这可以通过自定义或内置属性、组等实现。
理想的解决方案是:
- 轻松一次性将属性添加到多个帐户
- 不必添加到每个帐户
- 提供一些可能需要在创建帐户时设置的提示(视觉等)
答案1
组是与用户不同的一种对象,因此区分它们已经是可能的,甚至很容易。内置帐户通常留在用户容器中,而用户帐户和服务帐户通常被分类到用户容器下或用户容器外的单独 OU 中。无论哪种方式,按 OU 排序都是 GUI 中的视觉指示,并且也易于通过其他应用程序、powershell 命令、搜索等进行搜索和排序。
因此,只需按用户类型将用户分类到不同的 OU 中即可。您可能还想创建一个 OU 树,以便更细致地对人类用户进行分类,例如,您可以按部门将他们分类到单独的部门 OU 中。或者,您可以按办公地点或任何具有商业意义的方式对他们进行分类。这样,您就有多种方式来区分具有不同需求的用户。
我还喜欢将所有组分类到 OU 中。我要么创建一个组 OU,然后对其中的所有组进行分类,甚至创建一个 OU 树结构来区分用户组、资源组和分发组,要么将组包含在适当的用户 OU 中的用户旁边。
如果您没有将 AD 对象智能地分类到 OU,那么您将错过 Active Directory 的主要功能。
除了使用 OU,您还可以(确实应该)利用组成员身份。通常,有理由创建一个或多个用户和通讯组,其中包括组织的所有人员,但不包含任何内置或服务帐户。您可能还想为所有服务帐户创建一个分发和/或用户组(您可能能够将服务帐户的适当权限分配给组)。通讯组完全是为了对用户进行分类,几乎没有其他用途(特别是如果您不使用 Exchange),因此它是将帐户分组用于各种目的的理想机制。
如果你做有了 Exchange,您就会得到添加到 Active Directory 的各种架构扩展,您可以使用它们来区分用户邮箱和共享邮箱等。
最后,关于服务帐户,您可以考虑一下各种服务帐户所需的范围。如果您的服务需要自定义帐户但不需要访问任何网络资源,您可以简单地为该服务创建一个本地帐户,并在本地计算机上授予其必要的权限。这样可以减少一个服务帐户来扰乱您的 AD。
答案2
除了@Todd Wilcox
的优秀答案之外,我想添加有关 AD 中对象的命名约定的想法。
您希望为用户/组创建的“属性”的某些方面可以通过对对象和基础设施制定非常严格的命名约定来固有地应用,并且不偏离从中。
用户
常规用户名应为<FirstName>.<LastName>
、 或<lastName><FirstInitial>
,而其显示名称应为<LastName>, <FirstName> (<Department>)
。或任何适合您公司的名称。无论哪种方式,它们都应该是可复制的,并且格式应这样一种方式:如果您知道某个用户的某个元素,您就知道如何找到有关他们的更多信息,因为您知道要查找什么。
Real Name Department Display name User Name
John Doe IT Doe, John (IT) John.Doe
Jane Doe Finance Doe, Jane (FIN) Jane.Doe
James Doe Human Resources Doe, James (HR) James.Doe
服务账户也应该遵循标准惯例,但是不同的比普通用户的帐户要多。这也适用于“共享”帐户,但我无论如何都会远离这些帐户。我首选的格式是sa.<vendor>.<product>
,这样可以很容易地对它们进行分组并找到它们以供以后重复使用。
Vendor Product Display Name Username
VMware vSphere (SA) VMware - vSphere sa.vmware.vsphere
Microsoft SQL Server (SA) Microsoft - SQL Server sa.microsoft.sqlserver
Microsoft Exchange (SA) Microsoft - Exchange sa.microsoft.exchange
IBM Tivoli Storage Manager (SA) IBM - Tivoli Storage Manager sa.ibm.tsm
群组
安全组应根据其所做的事情和适用范围来命名,但同样要遵循标准模式,以便可以轻松找到具有类似目的的群体。
文件共享可以通过共享名称和其授予的权限来命名,而该共享的服务器/路径可以在描述中找到(SHR_<ShareName>_R
用于读取,SHR_<ShareName>_M
用于修改)。
通用邮箱访问组,可以包含邮箱名称和权限(GM_<SMTPAddress>_FMR
完全访问、GM_<SMTPAddress>_SA
发送为)。
AD/服务器委派组可以是团队的名称(DLG AD DevOps)
,,DLG SRV BackupAndStorage
等等)
分发列表是唯一奇怪的列表,因为它可能会被命名为或多或少任何需要的名称,因为人们会想要这样。但即便如此,您也可以为它们设置适合您的组织的标准。
答案3
我工作过的大多数环境都不会对帐户属性执行此操作。他们通过 OU 组织和/或命名标准来执行此操作。一个简单的例子可能是:
- (域根)
- 所有账户
- 人类
- 共享帐户
- 服务帐户
- 所有账户
如果有意义,您可以细分不同的帐户类型。但大多数情况下,您只需要群组成员身份即可进一步划分人群。为非人类帐户类型添加标准前缀/后缀也可以使其更容易一目了然地查看/管理。例如,所有服务帐户可能都以“svc.”开头。