目前，它本质上是一堆脚本，由内部开发的基于 Perl 的控制台菜单执行。每个脚本都与创建过程中的一个步骤相关联。菜单看起来像这样：
连接到数据库并将新学生转储到 CSV 文件中
在最新转储中为学生创建 LDAP 帐户
在最新转储中为学生创建 ActiveDirectory 帐户
在数据库中记录新帐户
归档 CSV 文件
输入选择：____
菜单有一个配置文件，其中包括每个步骤所需的密码和脚本以及菜单结构。密码在内存中保持加密。
虽然这个过程现在有效，但我们正在尝试用这种方法解决几个问题：
我们需要一个合理的锁定机制。
我们正在从使用 Perl 转向使用 Python 进行 SysOps 开发。
我们现在正处于这个项目的研究阶段。
其他组织如何处理？我对其他大学如何管理帐户配置特别感兴趣。在学期中期，我们通常每周有十几个新帐户。但是，在几周内每年 3 次，我们有 1,000 多个帐户需要配置。
对我们来说很重要的一件事是密码管理。在创建期间，这些帐户在大约 5-8 个系统中提供。所有这些系统的密码都是独一无二的，而且很难——如果不是不可能——记住。我们当前的菜单系统允许我们让会话保持打开状态，并且密码在内存中加密。在新系统中有类似的机制会很好。谁有想法？
既然你问...
我是一所大型大学的系统管理员。我们有 20,000 到 24,000 个帐户，具体取决于我们在学区的位置以及州政府是否要求我们接受更多学生。自从我们第一次开始批量向学生提供计算机帐户（如果我没记错的话，可以追溯到 VAX 时代）以来，帐户配置是我们一直必须解决的问题。因此，我们在真正的商业解决方案出现之前就开发了帐户管理。
在过去十年的大部分时间里，我们需要提供三个主要的身份孤岛：
在过去的 12 个月里，我们刚刚设法关闭了最后两个，只剩下一个主要的身份存储。不过，做三件事的记忆还是很新鲜的。
帐户创建过程如下所示：
因为我们运行三个独立的环境，所以我们很早就设计了一个完全独立的密码管理系统。这与创建者的身份系统挂钩。学生转到密码重置页面，完成整个过程，这反过来又会向 ID 引擎启动事件以更新密码。我们还将密码老化和复杂性规则作为这个自制系统的一部分。
以上所有代码都是我们构建的，并且非常自动化。人工输入是进入 Banner 的数据条目，最初输入学生详细信息。符合条件的帐户状态在 Banner 中处理，因此即使删除也是完全自动化的。
员工帐户的处理方式相同，尽管这些更新中有更多的目录数据（FERPA 要求说我们不应该对学生做那种事情）。
仍然有大量人工输入的一个领域是状态变化，例如学生到员工，反之亦然。这完全是因为对于学生工人和雇员上课之间的模糊界限应该在哪里缺乏共识。经过近十年的抱怨，这才刚刚被同意，所以我们希望现在甚至可以将这些自动化。
另一个减少了我们将密码推送到更多系统的需要的领域是无情地推动对基于 Web 的任何事物进行 SSO 化。我们为此使用 CAS，它运行良好。正因为如此，我们不必将密码输入 Blackboard，以及任何大学最终使用的各种奇怪的应用程序。
我们甚至为我们的 Helpdesk 员工创建了一个网络应用程序，它利用这个系统来处理 AD 中的入侵者锁定、组成员身份更改和计算机对象位置移动等问题。这减少了SysAdmin 员工（嗨！）的日常工作负载，以至于我们正在做比从帮助台发送给我们的日常工作任务更多的面向未来的项目内容。
如果我必须从头开始做这一切，我可能会使用一些现在存在的非常好的身份管理框架。Novell 的 Identity Manager 非常非常好，但遗憾的是非常非常昂贵。现在我们正在使用的编译代码几乎每一步的方式，这意味着我们有两个系统程序员（一个用于Windows端，一个用于Unix方），其突然死亡会导致大学作为一个整体的世界伤害. 使用 3rd 方应用程序来实现这一关键功能意味着我们已经大大减轻了我们目前拥有的“啤酒卡车漏洞”。
然而，这个解决方案就像手套一样适合我们的需求；因此，摆脱它会让人觉得花更多的钱购买效果较差的东西，因此没有吸引力。