Как крупные организации с большим оборотом и многими системами выполняют подготовку учетных записей?

Наше текущее решение

На данный момент это, по сути, набор сценариев, которые выполняются с помощью собственного разработанного консольного меню на основе Perl. Каждый сценарий связан с шагом в процессе создания. Меню выглядит примерно так:


Создание учетной записи студента

  1. Подключитесь к базе данных и добавьте новых студентов в файл CSV

  2. Создание учетных записей LDAP для студентов в последнем дампе

  3. Создать учетную запись ActiveDirectory для студентов в последнем дампе

  4. Записать новый аккаунт в базу данных

  5. Архивировать файл CSV

Введите выбор: ____


В меню есть файл конфигурации, в котором указаны пароли и сценарии, необходимые для каждого шага, и структура меню. Пароли хранятся в зашифрованном виде в памяти.

Хотя этот процесс работает прямо сейчас, мы пытаемся решить несколько проблем с помощью этого подхода:

  1. Нам нужен разумный механизм блокировки на месте.

  2. Мы отошли от использования Perl и теперь используем Python для разработки SysOps.

Сейчас мы находимся в стадии исследования этого проекта.

Мой вопрос

Как другие организации справляются с этим? Меня особенно интересует, как другие университеты управляют предоставлением учетной записи. В середине школьного семестра у нас обычно есть десяток новых учетных записей в неделю. Однако три раза в год в течение нескольких недель у нас есть более 1000 учетных записей, которые необходимо подготовить.

Одна вещь, которая важна для нас, это управление паролями. Эти учетные записи предоставляются примерно в 5-8 системах при создании. Все эти системы имеют уникальные пароли, которые трудно - если не невозможно - запомнить. Наша текущая система меню позволяет нам оставить сеанс открытым, а пароли зашифрованы в памяти. Было бы неплохо иметь подобный механизм в новой системе. У кого-нибудь есть идеи?

2 ответа

Решение

Так как ты спросил...

Я сисадмин в большом университете. У нас есть от 20000 до 24 000 учетных записей, в зависимости от того, где мы находимся в учебном квартале и от того, обязал ли штат нас принять больше студентов. Подготовка учетной записи - это проблема, которую нам приходилось решать с тех пор, как мы впервые начали массово предоставлять учащимся учетные записи компьютеров (еще в дни VAX, если я правильно помню). Поэтому мы разработали систему управления учетными записями задолго до того, как появились реальные коммерческие решения.

На протяжении большей части прошлого десятилетия у нас было три основных хранилища идентификаторов, которые нам нужно было обеспечить:

  • Microsoft Active Directory
  • Novell eDirectory
  • NIS-плюс

за последние 12 месяцев нам только что удалось отключить два последних, и у нас остался только один крупный фирменный магазин. Тем не менее, память о выполнении трех еще свежа.

Процесс создания учетной записи выглядит следующим образом:

  1. Студент помечен как имеющий право на учетную запись.
  2. Один раз в день экспорт CSV создается и сбрасывается на нужный сервер.
  3. Файл CSV обрабатывается в соответствии с состоянием NIS+, применяя изменения.
    • Создаются новые студенты и квота на домашний каталог
    • Аккаунты учащихся, не отвечающие критериям, отключены (и через 2 недели удалены)
    • Текущие студенты обновляют данные своего каталога по мере необходимости (например, полное имя, фамилия)
  4. Затем файл обрабатывается механизмом идентификации AD/eDir.
    1. Учетные записи создаются по мере необходимости, в том числе домашние каталоги, группы по умолчанию, набор квот на печать, электронная почта для учащихся ([email protected]) и некоторые другие вещи, которые я, вероятно, забыл.
    2. Данные каталога обновляются для всех пользователей (полное имя, фамилия, а также для персонала и многих других деталей). Это перезаписывает любые ручные изменения, сделанные нативными инструментами, и это хорошо.
    3. Удаления обрабатываются так же, как сторона NIS.

Поскольку мы использовали три отдельные среды, мы с самого начала разработали совершенно отдельную систему управления паролями. Это подключается к той же системе идентификации, что и создатель. Студенты переходят на страницу сброса пароля, проходят через процесс, который, в свою очередь, запускает события для ID-машин для обновления паролей. Мы также применяем правила устаревания паролей и сложности в рамках этой домашней системы.

Все вышеперечисленное было разработанным нами кодом и очень автоматизировано. Вводимые человеком данные - это ввод данных в Banner, где первоначально вводятся данные об ученике. Статус подходящих для учетных записей обрабатывается в Banner, поэтому даже удаление полностью автоматизировано.

Учетные записи сотрудников обрабатываются одинаково, хотя в этих обновлениях содержится намного больше данных каталога (требования FERPA говорят, что мы не должны делать такие вещи со студентами).

Одна область, которая все еще имеет значительный человеческий вклад, связана с изменениями статуса, такими как Студент к Сотруднику и наоборот. Это полностью связано с отсутствием единого мнения о том, где должна быть нечеткая грань в песке между учеником-работником и учеником-учеником. Это ТОЛЬКО было согласовано после почти десятилетия ворчания, поэтому мы надеемся автоматизировать даже это сейчас.

Еще одной областью, которая уменьшила нашу потребность в внедрении паролей во все большее количество систем, стал безжалостный переход на единый веб-интерфейс. Для этого мы используем CAS, и он работает неплохо. Из-за этого нам не нужно вставлять пароли в Blackboard, а также обычный ассортимент странных приложений, которые заканчиваются в любом университете.

Мы даже создали веб-приложение для наших сотрудников службы поддержки, которое использует эту систему для обработки таких вещей, как блокировки нарушителей, изменения членства в группах и перемещения объектов компьютеров в AD. Это снизило ежедневную нагрузку на сотрудников SysAdmin (привет!) До такой степени, что мы выполняем намного больше проектов, ориентированных на будущее, чем ежедневные задачи измельчения, отправляемые нам из службы поддержки.


Если бы мне пришлось делать все это с нуля, я бы, вероятно, использовал некоторые из очень хороших фреймворков управления идентификацией, которые сейчас существуют. Novell Identity Manager очень, очень хороший, но, к сожалению, очень, очень дорогой. В настоящее время мы используем скомпилированный код практически на каждом этапе, а это означает, что у нас есть два системных программиста (один для стороны Windows, один для стороны Unix), чья внезапная смерть нанесла бы ущерб всему университету в целом., Использование стороннего приложения для этой важной функции означает, что мы бы значительно снизили "уязвимость пивного грузовика", которая у нас есть в настоящее время.

Тем не менее, это решение соответствует нашим потребностям как перчатка; так что избавиться от этого будет все равно, что тратить гораздо больше на то, что делает меньше, а значит, и непривлекательно.

Пока системы, в которые они входят, просят их создать новый пароль после первого входа в систему, этот метод кажется очень эффективным. Также может быть целесообразно связать создание пользователя LDAP с созданием пользователя в базе данных, чтобы сократить количество шагов, необходимых для ИТ-персонала.

Другие вопросы по тегам