На данный момент это, по сути, набор сценариев, которые выполняются с помощью меню консоли, разработанного внутри компании и основанного на Perl. Каждый сценарий связан с этапом процесса создания. Меню выглядит примерно так:
Подключитесь к базе данных и выгружайте новых студентов в файл CSV
Создайте учетные записи LDAP для студентов в последней дампе
Создайте учетную запись ActiveDirectory для студентов в последней дампе
Записать новую учетную запись в базу данных
Заархивируйте файл CSV
Введите выбор: ____
В меню есть файл конфигурации, в котором указаны пароли и сценарии, необходимые для каждого шага, а также структура меню. Пароли хранятся в зашифрованном виде в памяти.
Хотя этот процесс работает прямо сейчас, мы пытаемся решить несколько проблем с помощью этого подхода:
Нам нужен разумный запорный механизм.
Мы уходим от Perl и теперь используем Python для разработки SysOps.
Сейчас мы находимся на стадии исследования этого проекта.
Как с этим справляются другие организации? Меня особенно интересует, как другие университеты управляют подготовкой учетных записей. В середине учебного семестра у нас обычно появляется дюжина новых учетных записей в неделю. Однако три раза в год в течение пары недель у нас более 1000 учетных записей, нуждающихся в инициализации.
Для нас важно управление паролями. Во время создания эти учетные записи предоставляются примерно в 5-8 системах. Все эти системы имеют уникальные пароли, которые сложно - если вообще возможно - запомнить. Наша текущая система меню позволяет нам оставить сеанс открытым, а пароли зашифрованы в памяти. Было бы неплохо иметь аналогичный механизм в новой системе. У кого-нибудь есть идеи?
Поскольку вы спросили ...
Я сисадмин в большом университете. У нас есть от 20 000 до 24 000 учетных записей в зависимости от того, где мы находимся в академическом квартале, а также от того, требует ли государство, чтобы мы принимали больше студентов. Обеспечение учетной записи - это проблема, которую мы должны решить с тех пор, как мы впервые начали массово предоставлять студентам компьютерные учетные записи (если я правильно помню, во времена VAX). По этой причине мы разработали систему управления учетными записями задолго до того, как для этого появились реальные коммерческие решения.
На протяжении большей части последнего десятилетия у нас было три основных бункера идентификации, которые нам нужно было предоставить:
за последние 12 месяцев нам удалось отключить последние два, и у нас остался только один крупный магазин идентификационной информации. Тем не менее, воспоминания о выполнении трех еще свежи.
Процесс создания учетной записи выглядит так:
Поскольку мы запускали три отдельные среды, мы изначально разработали совершенно отдельную систему управления паролями. Это подключается к той же системе идентификации, что и создание. Учащиеся переходят на страницу сброса пароля, проходят процесс, который, в свою очередь, запускает события для механизмов идентификации для обновления паролей. Мы также выполняем правила устаревания и сложности паролей в рамках этой домашней системы.
Все вышеперечисленное было написано нами и полностью автоматизировано. Человеческий ввод - это ввод данных в баннер, где изначально вводятся данные студента. Статус правомочных аккаунтов обрабатывается в Banner, поэтому даже удаление полностью автоматизировано.
Учетные записи сотрудников обрабатываются одинаково, хотя в этих обновлениях гораздо больше данных каталога (согласно требованиям FERPA, мы не должны делать такого рода вещи со студентами).
Единственная область, в которой все еще есть значительный человеческий вклад, - это изменение статуса, например, от студента к сотруднику и наоборот. Это полностью связано с отсутствием консенсуса по поводу того, где должна быть нечеткая линия на песке между студентом-рабочим и сотрудником, посещающим занятия. Это ТОЛЬКО было согласовано после почти десятилетнего недовольства, поэтому мы надеемся автоматизировать даже это сейчас.
Еще одна область, которая уменьшила потребность во внедрении паролей во все большее количество систем, - это безжалостное стремление к единому входу в любой веб-системе. Мы используем для этого CAS, и он неплохо работает. Из-за этого нам не нужно вводить пароли в Blackboard, а также в обычный набор необычных приложений, которыми заканчивает любой университет.
Мы даже создали веб-приложение для сотрудников службы поддержки, которое использует эту систему для обработки таких вещей, как блокировка злоумышленников, изменение членства в группах и перемещение компьютерных объектов в AD. Это снизило ежедневную измельчительную нагрузку на Персонал системного администратора (привет!) до такой степени, что мы делаем гораздо больше перспективных проектов, чем ежедневные рутинные задачи, отправляемые нам из службы поддержки.
Если бы мне пришлось делать все с нуля, я бы, вероятно, использовал некоторые из очень хороших фреймворков управления идентификацией, которые сейчас существуют. Novell Identity Manager очень и очень хорош, но, к сожалению, очень и очень дорог. Прямо сейчас мы используем скомпилированный код почти на каждом этапе пути, а это значит, что у нас есть два системных программиста (один со стороны Windows, один со стороны Unix), внезапная смерть которых может привести к тому, что университет в целом Мир боли. Использование стороннего приложения для этой важной функции означает, что мы значительно снизили бы «уязвимость пивного грузовика», которая у нас есть.
Однако это решение соответствует нашим потребностям как перчатка; Так что, выходя из него, вы почувствуете, что потратите намного больше на то, что делает меньше и поэтому непривлекательно.
Пока системы, в которые они входят, просят их создать новый пароль после первого входа в систему, этот метод кажется очень эффективным. Также может быть целесообразно связать создание пользователя LDAP с созданием пользователя в базе данных, чтобы сократить количество шагов, необходимых ИТ-персоналу.