什么是你们遵循的过程，以维护authentication的详细信息，如loginID和密码？ 肯定会有一些共享的密码。 所以，目标是尽量减less有人离开公司时的影响。
我所说的“共享密码”是指在公司多人共享的帐户。
这个过程应该解决的问题是：
受影响的地区 。 快速find离开用户有权访问的资源。
忘记密码 。 如果用户忘记authentication详细信息会怎么样？ 他如何得到它？ 我想他不应该问队友。 我的意思是无言的交stream。
find资源的依赖关系 。 假设我正在更改一个邮件帐户的密码，这个帐户正在被一些自动化的脚本用来发送邮件。 在这里，脚本依赖于邮件帐户，所以更改邮件帐户的密码意味着我们也必须在脚本中更改密码。 那么，如何find资源的所有依赖关系呢？
我更喜欢一个解决这些问题的过程。 但是，您也可以推荐开放源代码而不是托pipe的产品。 我已经通过了PassPack ，但他们没有解决＃4。
这里也有类似的问题。 但是这并不能完全回答我的问题。
集中的账户pipe理将是第一步。 一个地方只有一个证书和一个地方 – 或者至less只有一个主logging被复制到其他系统，所以只有一个地方进行更改，包括禁用帐户。
当有人离开时，需要遵循的例行程序。 这可以是高度手动的，但仍然需要在整个公司进行编写和遵守。
无论谁负责一个特定的系统，所有的系统都必须有一个拥有者和一个pipe理员，需要遵守书面的政策，例如当有人离开时，如果他们的系统中有任何清理的话。
我只是简单地禁止共享帐户 – 一切都应该是个人的，包括路由器/交换机login和其他设备，因为某些原因，人们认为这是不可能的。 这是，一直是。
随机或删除计算机的本地pipe理帐户密码，不要使用任何东西。
资源/服务帐户应在需要更改时重新生成，或者升级到可以在后台自动pipe理服务帐户密码的系统（例如，使用Windows 2008 R2 for Windows系统）。 如果找不到依赖关系，我会把它归咎于缺乏文档或系统，认为像脚本中的硬编码密码这样的过时的思维过多。 立即扔掉这些解决scheme。
是的，这可能是很难或不可能做到的，但是总是为了乌托邦而努力 – 在中途，一切都已经变得更加顺利了^^
有许多公司提供的身份识别生命周期pipe理的许多概念和软件解决scheme – 包括微软在内 。 但是对于50人来说，大多数是纸质政策，对IT系统采取严格的实用方法 – 减less系统数量，坚持DRY（不要重复）原则，只购买与现有平台完美结合的系统（S）。