我们当前的解决方案

我们当前的解决方案

我们当前的解决方案

目前,它本质上是一堆脚本,由内部开发的基于 Perl 的控制台菜单执行。每个脚本都与创建过程中的一个步骤相关联。菜单如下所示:


创建学生帐户

  1. 连接到数据库并将新学生转储到 CSV 文件中

  2. 在最新转储中为学生创建 LDAP 帐户

  3. 在最新转储中为学生创建 ActiveDirectory 帐户

  4. 在数据库中记录新帐户

  5. 存档 CSV 文件

输入选择:____


菜单有一个配置文件,其中包含每个步骤所需的密码和脚本以及菜单结构。密码以加密形式保存在内存中。

尽管这个过程现在有效,但我们正在尝试用这种方法解决几个问题:

  1. 我们需要一个合理的锁定机制。

  2. 我们正在不再使用 Perl,而是使用 Python 进行 SysOps 开发。

我们目前正处于该项目的研究阶段。

我的问题

其他组织如何处理这个问题?我特别感兴趣的是其他大学如何管理帐户配置。在学期中期,我们通常每周都会有十几个新帐户。然而,每年有三次,在几周的时间里,我们有超过 1,000 个帐户需要配置。

对我们来说,密码管理非常重要。这些帐户在创建时会在大约 5-8 个系统中进行配置。所有这些系统的密码都是独一无二的,而且很难(甚至不可能)记住。我们当前的菜单系统允许我们保持会话打开,并且密码在内存中加密。如果新系统中有类似的机制就好了。有人有什么想法吗?

答案1

既然你问了...

我是一家大型大学的系统管理员。我们拥有 20,000 到 24,000 个账户,具体取决于我们在学术区的位置以及州政府是否要求我们接受更多学生。自从我们开始批量为学生提供计算机账户以来(如果我没记错的话,那是在 VAX 时代),账户配置就是我们不得不解决的一个问题。因此,我们在真正的商业解决方案出现之前就开发了账户管理。

在过去十年的大部分时间里,我们需要配置三个主要的身份孤岛:

  • 微软活动目录
  • Novell 电子目录
  • NIS 加

在过去的 12 个月里,我们刚刚成功关闭了最后两个,只剩下一个主要的身份存储。然而,关闭三个的记忆仍然历历在目。

账户创建过程如下:

  1. 学生被标记为有资格获得帐户。
  2. 每天创建一次 CSV 导出文件并将其发送到正确的服务器。
  3. 根据 NIS+ 状态处理 CSV 文件并应用更改。
    • 创建新学生并设置主目录配额
    • 不再符合条件的学生账户将被禁用(两周后将被删除)
    • 当前学生的目录详细信息已根据需要更新(例如全名、姓氏)
  4. 然后该文件由 AD/eDir 身份引擎处理。
    1. 帐户是根据需要创建的,包括主目录、默认组、设置的打印配额、配置的学生电子邮件(Live@Edu)以及我可能忘记的一些其他内容。
    2. 所有用户的目录详细信息都会更新(全名、姓氏,以及员工的许多其他详细信息)。这会覆盖本机工具所做的任何手动更改,这是一件好事。
    3. 删除处理与 NIS 端相同。

由于我们运行三个独立的环境,因此我们很早就设计了一个完全独立的密码管理系统。它与学生的身份系统挂钩。学生进入密码重置页面,完成流程,然后触发 ID 引擎事件以更新密码。我们还在这个自制系统中制定了密码时效和复杂性规则。

以上所有代码都是我们编写的,而且自动化程度很高。人工输入是将数据输入到 Banner 中,学生详细信息最初就是在这里输入的。账户资格状态在 Banner 中处理,因此即使删除也是完全自动化的。

员工帐户的处理方式相同,尽管这些更新中包含更多的目录数据(FERPA 要求我们不应该对学生做那种事)。

唯一一个仍需要大量人工投入的领域是身份变更,例如学生变为员工,反之亦然。这完全是因为缺乏共识,无法确定学生为员工和员工上课之间的界限应该在哪里。经过近十年的抱怨,我们终于达成了一致,所以我们希望现在就将这些都自动化。

另一个减少我们将密码输入更多系统的领域是,我们坚决推动将任何基于 Web 的东西都 SSO 化。为此,我们使用 CAS,效果很好。正因为如此,我们不必将密码输入 Blackboard,也不必输入任何大学都会使用的那些古怪的应用程序。

我们甚至为我们的帮助台员工创建了一个 Web 应用程序,利用该系统来处理入侵者锁定、组成员身份更改以及 AD 中的计算机对象位置移动等问题。这减少了系统管理员(嗨!) 到目前为止,我们正在做更多着眼于未来的项目,而不是帮助台发送给我们的日常繁琐任务。


如果我必须从头开始,我可能会使用一些现在存在的非常好的身份管理框架。Novell 的身份管理器非常非常好,但不幸的是非常非常昂贵。现在我们几乎每一步都使用编译代码,这意味着我们有两个系统程序员(一个负责 Windows 方面,一个负责 Unix 方面),他们的突然死亡将导致整个大学世界伤害。使用第三方应用程序实现这一关键功能意味着我们将大大减轻目前存在的“啤酒卡车漏洞”。

但是,这种解决方案非常符合我们的需求;因此,放弃它就像花更多的钱买一些功能更少的东西,因此没有吸引力。

答案2

只要他们登录的系统要求他们在首次登录后创建新密码,这种方法似乎就非常有效。将 LDAP 用户创建与数据库中的用户创建结合起来也可能很有价值,以减少 IT 人员所需的步骤数。

相关内容