识别和跟踪变得很重要，但出乎意料地困难。

首先，标记目录中的帐户，以便您可以将它们识别为非用户 ID。

每个非用户帐户都需要与帐户所有者相关联，该所有者负责保护其访问的系统。将所有者的身份存储在非用户 ID 的目录条目中，因此如果您稍后再寻找这些，您就知道应该联系谁。请记住，所有者随着员工升职、人员流动等来来去去，因此您可能需要一个部门或其他组织标签来与员工 ID 一起使用。群组成员可以在这里提供帮助。此外，当员工离开时，他们的目录帐户可能会被删除，从而使未知 ID 变得无用 - 名称至少是其他人可以帮助您追踪的人。

了解帐户与哪台机器相关联也可能会有所帮助。将该信息也保存在您的目录中。

如果您有一个正式的请求系统，人们在其中输入他们对请求帐户、机器等的要求，我会将请求编号存储在目录条目中。但请记住，请求跟踪系统可以更改，并且与 5 年前发布的跟踪号相关的信息可能不再可用。我建议您也将所有者和机器信息记录在案。

如果您的帐户还没有正式的审核流程，请考虑当您实施一个审核流程时，您的目录中将有一大堆非用户帐户。这些数据将帮助您识别审查者（系统所有者应定期审查这些审查是否合适。）考虑将审查数据与记录一起保存；您甚至可能希望在目录中保留“上次审核时间/由”信息以提供给审核员。

保留此信息的主要原因是为了以防万一。在响应阶段，您需要能够快速识别与帐户关联的人员，以便您可以轻松更改密码、扫描系统并快速追踪他们。请记住，您可能需要在不提醒系统所有者的情况下执行此活动，至少在调查处于活动状态时是这样。您可能还需要向调查人员提供审查信息。妥协可能源于内部来源，这是一个可悲的现实。

要回答您的其余问题，您应该使用加密强密码生成器（不是 javascript 的 random()）生成一个冗长的密码。如果您可以在不涉及人工的情况下分配这些帐户和密码，使用密码管理工具，那就更好了。有一些商业系统与 ldap 服务器绑定来完成大部分工作（因为您是 Oracle 商店，您应该咨询您的客户代表，因为他们出售这样的系统。）

一般来说，为自动化创建的用户和为真实的人创建的用户之间没有很大的区别。您仍然应该将每个用户的访问权限限制在所需的范围内。

考虑如何将 3rd 方服务访问权限划分为受信任的资源有点模糊。一个人通常只有一个帐户，我们不会为每个用户创建多个帐户（有一些例外）。但是您的“服务”可以通过多种方式来考虑。只有您可以确定如何描述这一点，以及您可能认为单一服务的不同部分是否需要不同级别的访问。

例如，有一个众所周知的邮件服务器，称为 postfix。在高层次上，您可以将 postfix 视为单个服务。在较低的级别上，它实际上设计了多个流程来构成其中的每个服务。每个进程都拥有完成工作所需的最少权限。

使用第 3 方软件，您可能会或可能无法完成“最小特权”的做事方式。但是，在设置与实际人员打交道时不那么相关的自动化时，它仍然是一个重要的设计考虑因素。

1. 其他评论员建议使用证书而不是 LDAP - 但如果您不能轻松做到这一点，我不会建议使用 2 种身份验证机制。拥有一个身份验证系统将确保实施不佳的可能性降低。
2. 对于强密码，使用“UUID-type 4”生成器算法 - 这将为您提供一个适合您的随机字符串（它不会被猜测）。
3. 未被应用程序使用的用户的弱点是拥有用户的完全权限，而他们可以由有权访问他们的任何人控制（因此前雇员可能仍然可以访问他们） - 确保对此类应用程序的访问权限是托管（连同他们的权限 - 只给他们足够的权限让他们工作）。还要谨慎管理密码到期 - 如果应用程序不包含此类到期选项并将其启用，它可能会在意外时间停止工作。