Пользователи часто обращаются в службу поддержки из-за проблем с учетными записями Windows 2000 и Windows NT 4.0, требующих вмешательства администратора, например для восстановления забытого пароля. Она самостоятельного управления учетными записями поможет повысить эффективность работы ИТ-подразделений и сократить затраты. Модель основана на реализованной в COM+ концепции ролей (impersonation) и дает пользователям возможность менять свои пароли и разблокировать учетные записи в AD. В средах с высоким уровнем защиты пользователям запрещено управлять собственными учетными записями, но такая модель позволяет повысить безопасность, используя сохраненные личные данные для идентификации сотрудника, обратившегося в службу поддержки.

Как построить безопасную службу самостоятельного управления учетными записями? Можно купить готовую систему у независимого поставщика, но во многих случаях лучше спроектировать простое и недорогое решение на базе Web с использованием объектов ActiveX (ActiveX Data Object, ADO), интерфейсов ADSI (Active Directory Service Interfaces) и страниц ASP (Active Server Pages). В целом решение должно выполнять три основные функции: сбор данных, аутентификацию пользователя и управление учетной записью. Во-первых, необходима программа для сбора информации, с помощью которой можно наполнить базу данных сведениями, уникально идентифицирующими пользователей. Во-вторых, нужно построить защищенный механизм идентификации пользователей, в котором используются не традиционные пароль и имя пользователя, а информация из базы данных. В-третьих, можно расширить механизм аутентификации, чтобы разблокировать учетную запись и обновить пароль от лица пользователя. Я подготовил пример решения (вместе с документированным исходным текстом), который читатели могут загрузить и адаптировать к своей среде. Получить необходимые материалы можно здесь.

Этап 1. Сбор данных

Чтобы определить круг собираемых данных, сначала необходимо решить, как лучше всего идентифицировать пользователя, не прибегая к традиционному паролю и имени. Существует много нетехнических вариантов такого типа идентификации. Например, телефонный разговор клиента с представителем финансового учреждения неизбежно начинается с нескольких вопросов, которые позволяют с большой долей вероятности установить личность клиента. В некоторых организациях достаточно знать адрес и номер счета, тогда как в других — задают вопросы о личных данных, например о девичьей фамилии матери или пароле счета. Затем абоненты могут перейти к деловому разговору, будь то баланс счета, продажа или покупка ценных бумаг.

Экран 1. Получение информации от пользователя.
Приступая к сбору частных сведений о пользователях, нужно построить на томе NTFS Web-страницу (data_collection.asp в примере), на которой представлено от четырех до шести вопросов (см. Экран 1). Эти вопросы должны соответствовать нескольким критериям. Полученные частные сведения должны быть известны только данному пользователю, отсутствовать в корпоративных или общедоступных базах данных и не раскрываться методами социальной инженерии (т. е. взломщик не может отгадать правильные ответы, почерпнуть сведения из случайного разговора или произвести наблюдения за действиями пользователя). Кроме того, ответы должны быть статическими (т. е. оставаться одинаковыми при перемене должности или места жительства). Этим критериям не соответствуют вопросы о подразделении, в котором работает пользователь, домашнем адресе или номере телефона. Выбрать вопросы, соответствующие предъявленным требованиям, непросто, особенно в транснациональных организациях, не все сотрудники которых имеют номера социальной защиты или водительских прав.

Однако почти каждый человек может указать генеалогическую информацию: например, дату свадьбы родителей, год рождения матери или имя деда по материнской линии. Такие сведения редко сообщают случайным знакомым, поэтому они могут быть полезной статической информацией. Можно использовать вопросы, открытые для интерпретации пользователем, например о памятной дате. Тип даты заранее не оговаривается, она может быть любой — от дня рождения до даты поступления на работу. Пользователям можно предоставить и возможность самим сформулировать вопрос и ответ. Подобный метод, вероятно, самый надежный, поскольку взломщикам придется отгадывать как вопрос, так и ответ. Однако подбор ответов, отвечающих всем необходимым критериям, может вызвать затруднения, поэтому вряд ли разумно при выборе вопросов целиком полагаться на пользователя. Данные будут одновременно статическими и трудными для отгадывания, если использовать комбинацию готовых и придуманных вопросов.

В процессе подготовки программы сбора данных необходимо построить трехуровневую архитектуру, состоящую из внутренней базы данных, объекта COM, взаимодействующего с базой, и ASP-кода, который обеспечивает интерфейс с пользователем.

В базе данных примера приложения определены две таблицы: Predefined_Questions и Collected_Data. В таблице Predefined_Questions хранятся заранее подготовленные вопросы, предлагаемые пользователю (например, назовите девичью фамилию матери). В таблице Collected_Data хранятся пользовательские ответы. В примере сценария используется база данных Microsoft Access 2000, но источник ADO для объекта COM легко изменить, чтобы задействовать любую ODBC-совместимую базу данных.

Процедура сбора данных начинается, когда пользователь переходит к программе data_collection.asp. Сценарий создает экземпляр authenticate.dll с помощью включаемого файла instantiate.inc, показанного в Листинге 1.

Фрагмент A программы data_collection.asp (см. Листинг 2) вызывает метод GetNumberOfPredefinedQuestions. Данный метод определяет число заранее подготовленных вопросов, хранящихся в базе данных. Во фрагменте B (см. Листинг 2) эта величина используется в цикле, который вызывает метод DisplayPredefinedQuestion и генерирует HTML-код для показа готовых вопросов и соответствующих текстовых полей для ввода ответов.

Исходный текст Листинга 3 отображает специальные пары «вопрос-ответ» в Data_collection.asp. После того как пользователь завершит ввод информации и отошлет форму, сценарий передает данные в confirmation.asp.

Если confirmation.asp обнаруживает данные во всех полях, происходит вызов метода WriteDB COM-сервера, который шифрует данные с использованием алгоритма RC4, а затем Base64 шифрует результат (см. Листинг 4).

В итоге информация в базе данных надежно защищена. Если взломщик преодолеет собственную защиту базы данных, то ему не удастся прочитать сохраненные данные, не разгадав алгоритма шифрования. В качестве аргумента функции WriteDB указывается UID. В .asp-файлах примера UID определен как Request.ServerVariables («Auth_User»), который задействует имя пользователя, представленное им для аутентификации. В Microsoft Internet Information Services (IIS) 5.0 допускается стандартное имя пользователя (domainusername) или полное имя пользователя (user principal name, UPN). UPN стоит применять в средах Windows XP и 2000, так как это позволит задействовать простой механизм для представления имен пользователей, не требуя от них никаких сведений, кроме адреса электронной почты. В идеальном случае он соответствует механизму регистрации пользователей на рабочих станциях. Если какие-нибудь данные отсутствуют, то confirmation.asp вызывает подпрограмму ValidationError (см. Листинг 5) и возвращает пользователя в data_collection.asp.

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

Этап 2. Аутентификация пользователя

Очевидный вопрос, который возникнет у пользователя относительно любой программы самостоятельного администрирования учетной записи, — как управлять учетной записью, если невозможно зарегистрироваться? Если пользователю не удается получить доступ к доменной учетной записи (например, он забыл пароль), то он может обратиться к программе администрирования учетной записи с помощью любого браузера (в частности, с рабочей станции своего коллеги). Существуют и более сложные решения: например, интеграция с системой голосовой связи, или изменение экрана регистрации, предоставляемые независимыми поставщиками, или — если позволяют ресурсы и техническая квалификация — возможно дальнейшее развитие собственного проекта. Поскольку в приложении традиционный механизм аутентификации не используется, необходимо настроить все административные Web-страницы на анонимный доступ.

Экран 2. Начальная аутентификация.
Пример административного приложения начинается с ssa.asp. На этой странице начальной аутентификации система просит пользователя ввести простой фрагмент информации: например, UPN, адрес электронной почты, комбинацию имя домена/имя пользователя, идентификационный номер работника или другой уникальный идентификатор. Для дополнительной безопасности можно использовать один из контрольных вопросов (допустим, о девичьей фамилии матери), как показано на Экране 2.

Начальная страница не позволяет посторонним лицам узнать полный набор критериев, служащих для аутентификации пользователей, и облегчает применение уникальных для каждого сотрудника пар «вопрос-ответ». В скрытом поле данной страницы хранится номер вопроса, использованного для начальной аутентификации, чтобы не повторять его на основной странице аутентификации.

Экран 3. Дополнительная аутентификация.
Пользователь заполняет форму, данные из которой передаются в ssa_confirmation.asp (см. Экран 3). Далее программный код выводит на основную страницу аутентификации остальные вопросы и варианты действий, которые может совершить пользователь (например, снять блокировку, сбросить пароль). Пользователь выбирает действие, отвечает на все вопросы и отсылает форму. Приложение передает ответы пользователя для обработки в COM-сервер. В дополнение к базовой проверке элементов начальной формы ssa_confirmation.asp вызывает метод AuthenticateChallengeResponsePairing COM-сервера, чтобы сравнить представленную информацию со значениями в базе данных.

Метод Authenticate ChallengeResponsePairing принимает имя пользователя, номер вопроса и ответ; шифрует имя пользователя и отыскивает его в базе данных; возвращает совпадающую запись; расшифровывает данные. Если данные, введенные пользователем, совпадают с соответствующими данными в базе данных, то приложение возвращает булево значение True, и система признает пользователя идентифицированным.

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

Этап 3. Управление учетной записью

После того как пользователь идентифицирован программой, проверенные данные передаются в authenticate.asp. Этот сценарий вновь проверяет информацию, форматирует личные данные пользователя в строку с разделителями и передает строку и информацию о выполняемом действии в функцию AuthenticateUser. Метод AuthenticateUser сравнивает ответы с данными в базе данных и вызывает метод AuthenticateUser COM-сервера, чтобы выполнить действие.

Обычно, для того чтобы сбросить пароль, пользователь (или специалист службы поддержки, вводящий информацию от его имени) должен иметь права администратора; для любых операций по управлению учетными записями необходим некоторый уровень административных прав. Однако данное приложение реализовано как объект COM/COM+ и запускает COM-сервер в контексте службы Windows 2000 Component Services (на системах Windows 2000 и IIS 5.0) или пакета Microsoft Transaction Server (MTS) (на системах NT 4.0 и IIS 4.0), которому назначены права административной учетной записи. Поэтому пользователь (т. е. учетная запись IUSR) может запустить функцию AuthenticateUser в контексте более мощной учетной записи. Из соображений безопасности необходимо, чтобы методу AuthenticateUser были переданы и личные данные целевого пользователя. Сценарий проверяет данные перед тем, как разблокировать учетную запись или обновить пароль. Концепция делегирования COM слишком сложна, чтобы подробно объяснить ее в данной статье. Полностью она рассматривается в статье «Making the Transition: Multi-Tier Development for System Administrators» (http://www.microsoft.com/ technet/ ittasks/ deploy/ making.asp).

Экран 4. Подтверждение выполнения операции.
Затем приложение использует ADSI и COM-сервер, чтобы возвратить булево значение, представляющее событие верификации, и разблокирует учетную запись, сбрасывает пароль или выполняет любую комбинацию действий. Если действия выполнены успешно, то на экран выводится сообщение, подтверждающее, что учетная запись идентифицирована и разблокирована или же установлен новый пароль (см. Экран 4).

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

ТОМАС ЭК — руководитель группы разработки в Perot Systems. Имеет сертификаты MSCE+Internet, MSCD, ASE.