目前，它基本上是一堆由基于Perl的内部开发的控制台菜单执行的脚本。 每个脚本都与创build过程中的一个步骤相关联。 菜单看起来像这样：
连接到数据库并将新学生转储到CSV文件
为最新转储中的学生创buildLDAP帐户
为最新转储中的学生创buildActiveDirectory帐户
在数据库中logging新帐户
归档CSV文件
input选项：____
该菜单有一个configuration文件，其中包括每个步骤和菜单结构所需的密码和脚本。 密码保存在内存中。
虽然这个过程目前正在进行，但我们正在尝试用这种方法解决几个问题：
我们需要一个合理的locking机制。
我们正在摆脱使用Perl，现在使用Python进行SysOps开发。
我们现在正处于这个项目的研究阶段。
其他组织如何处理这个问题？ 我对其他大学如何pipe理帐户configuration特别感兴趣。 在学期中间，我们通常每周有十几个新帐户。 然而，一两个星期一年三次，我们有超过1000个需要configuration的帐户。
有一点对我们很重要，那就是密码pipe理。 这些帐户在创build期间在约5-8个系统中进行configuration。 所有这些系统的密码都是独一无二且难以记忆的。 我们目前的菜单系统允许我们打开会话，密码在内存中encryption。 在新的系统中有一个类似的机制是很好的。 有人有主意吗？
既然你问了…
我是一个大学的系统pipe理员。 我们有两万到二万四千个帐户，取决于我们在学区的位置以及国家是否已经授权我们接受更多的学生。 自从我们第一次开始给学生计算机账户（如果我记得没错的话，回到VAX的日子），帐户configuration是我们必须解决的问题。 因此，我们在开发真正的商业解决scheme之前就开发了帐户pipe理。
在过去十年的大部分时间里，我们需要提供三个主要的身份authentication：
在过去的12个月中，我们刚刚设法closures了最后两个，只留下了一个主要的身份识别商店。 但是，三人的记忆还是新鲜的。
帐户创build过程如下所示：
因为我们运行了三个独立的环境，我们在早期devise了完全独立的密码pipe理系统。 这挂钩到创build相同的身份系统。 学生们进入密码重置页面，通过这个过程，这个过程开始启动ID引擎来更新密码。 我们也做密码老化和复杂性规则作为这个家庭build成系统的一部分。
以上所有内容都是我们编写的代码，非常自动化。 人员input是inputBanner的数据，最初input学生的详细信息。 符合条件的帐户状态在横幅内处理，所以即使删除也是完全自动的。
工作人员帐户的处理方式是一致的，尽pipe这些更新中有更多的目录数据（FERPA要求我们不应该与学生做这样的事情）。
仍然有重要人力投入的一个领域是状态变化，例如学生到员工，反之亦然。 这完全是由于对沙子中的模糊线应该在学生工作者和雇员接受class之间缺乏共识。 这已经被接受了近十年的抱怨，所以我们希望现在甚至自动化这些。
另一个降低了我们将密码推送到更多系统的需求的领域已经成为SSO的无情推动 – 如果有任何基于networking的话。 我们使用CAS来做到这一点，并且工作得很好。 正因为如此，我们不必将密码推送到Blackboard，以及任何大学最终的奇怪应用程序的常见分类。
我们甚至为我们的帮助台人员创build了一个Web应用程序，利用这个系统来处理诸如入侵者locking，群组成员更改以及AD中的计算机对象位置移动等事情。 这已经减less了SysAdmin员工的日常研究负担（嗨！），以至于我们正在做更多的未来前瞻性的项目，而不是从帮助台发送给我们的日常研究任务。
如果我必须从头开始，那么我可能会使用现在存在的一些非常好的身份pipe理框架。 Novell的Identity Manager非常非常好，但是非常非常昂贵。 现在我们几乎每一步都使用编译代码，这意味着我们有两个系统程序员（一个用于Windows端，另一个用于Unix端），他们的突然死亡会导致整个大学受到伤害。 使用这个关键function的第三方应用程序意味着我们将大大缓解我们目前拥有的“啤酒卡车脆弱性”。
但是，这个解决scheme恰如我们的需要， 所以放弃它会觉得花更多的东西，less一些，因此没有吸引力。
只要他们login的系统要求他们在第一次login后创build一个新的密码，这个方法看起来非常有效。 通过在数据库中创build用户来配合LDAP用户创build也是值得的，以减lessIT人员所需的步骤数量。