Обработчик событий аутентификации пользователей Outlook Web Access

Те администраторы почтовых систем, которые используют у себя службу Outlook Web Access, знают, как много требуется времени и усилий, чтобы получить информацию о том, кто, когда, с какого IP-адреса пользовался службой, анализируя журнальные файлы Web-сервера напрямую, без применения каких-либо специальных средств. Предлагаемые два сценария помогают решить эту проблему. С их помощью можно в удобном виде просмотреть все попытки успешной или ошибочной аутентификации пользователей Outlook Web Access и получить более подробную информацию о попытках аутентификации, а именно: имя при регистрации пользователя, отображаемое имя в Active Directory, дату и время регистрации, IP-адрес источника, результат аутентификации, возвращаемый код HTTP.

Готовим базу

Обработчик состоит из двух сценариев — сценария обработки журнальных файлов сервера Outlook Web Access и записи событий из файлов в базу данных сервера SQL Server и сценария ASP, который обеспечивает интерфейс доступа для просмотра этой базы данных. Конечно, вовсе не обязательно применять сценарий ASP для просмотра информации, ее можно извлекать из базы данных любым удобным способом или просматривать напрямую через консоль Enterprise Manager.

Рисунок. Взаимодействие компонентов при анализе журнальных файлов

Сценарий обработки журнальных файлов сервера Outlook Web Access может запускаться не чаще чем раз в сутки, и особых требований к системе не предъявляет. Каких-либо особых требований к серверу SQL Server (я использовал версию SQL Server 2000) тоже не отмечается, важно его наличие. Для средних организаций за год база данных обычно вырастает не более чем до десятков-cотен мегабайтов. Web-интерфейс ASP также не предъявляет особых требований к серверу, главное, чтобы ему было на чем работать, т. е. чтобы был установлен Internet Information Server. Схематично взаимодействие компонентов показано на рисунке.

Кто и что делает

Сценарий обработки журнальных файлов написан на VB Script. Для работы сценария требуется, чтобы на Internet Information Server сервера Outlook Web Access была настроена запись журнальных файлов в формате W3C Extended Log File Format. Должна быть обязательно включена запись полей date, time, cs-method, cs-uri-stem, cs-username, c-ip, sc-status, так как эти поля обработчик использует в своей работе. По результатам работы он создает журнальный файл в формате html, который называется <ИмяКомпьютера НаКотором Запускался Обработчик>.htm. Создается файл в том же каталоге, где находится обработчик. Требуются разрешения на доступ с правом изменения к каталогу, где размещены журнальные файлы сервера Outlook Web Access и разрешения на запись в базу данных SQL Server. Работа с сервером SQL Server проходит в режиме аутентификации Windows.

Полный текст сценария приведен в файле OWALog.vbs, его можно будет найти на сайте журнала Windows IT Pro/RE.

Схематично сценарий состоит из трех секций:

  • входные переменные;
  • подготовка к работе, проверка требуемых условий;
  • обработка.

Рассмотрим эти секции по порядку.

Секция входных переменных. В секции задаются исходные переменные, необходимые для работы сценария:

  • переменная OWALogs содержит путь (UNC или локальный) к каталогу, в котором расположены журнальные файлы сервера IIS Outlook Web Access (обычно это OWAServerNamec$ WINDOWS system32 LogFiles W3SVC1);
  • ADSearch — массив, содержащий кратные трем значения, каждая тройка — это NetBIOS-имя домена, имя контроллера этого домена, путь LDAP начала поиска. Например, для леса Windows из двух доменов он будет выглядеть так:

ADSearch = Array(«NetBiosDomainName1»,»dc1.example1.com»,»dc=

example1,dc=com»,_

«NetBiosDomainName2»,»dc2.example2.com»,»dc=example2,dc=

com»)

Если лес Windows состоит из одного домена, массив будет содержать только три значения, при двух доменах в лесе — шесть значений и т. д. Этот массив служит для поиска соответствия имени регистрации пользователя отображаемому имени пользователя в Active Directory (DisplayName);

  • SQLServerName — имя сервера SQL Server;
  • SQLDataBaseName — имя базы данных SQL Server 2000;
  • SQLTableName — имя таблицы базы данных SQL Server 2000.

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

Проверки, проводимые в этой секции, таковы:

  • доступность каталога, в котором располагаются журнальные файлы сервера IIS Outlook Web Access, заданного во входной переменной OWALogs;
  • правильность (кратность трем) задания массива ADSearch входных переменных;
  • доступность для записи каталога OWALogs;
  • наличие журнальных файлов для обработки в каталоге OWALogs;
  • наличие утилиты csvde.exe в каталоге %SystemRoot%System32 на компьютере, где запускается сценарий обработки; утилита требуется для экспорта из Active Directory. По умолчанию она имеется в операционной системе Windows Server.
  • проверка доступности контроллеров домена и путей LDAP начала поиска, заданных в массиве ADSearch; осуществляется путем экспорта необходимых для работы сценария значений из Active Directory этих доменов и проверки наличия файлов экспорта. Имена файлов экспорта формируются в виде N.csv. Если хотя бы один файл экспорта отсутствует, работа сценария завершается с соответствующей записью в журнальный файл (см. листинг 1).

Секция обработки. Вся необходимая обработка данных производится в этой секции. На основании содержимого каждого из файлов экспорта из Active Directory строится массив значений CSVArray(), кратный четырем (см. листинг 2).

В каждой четверке содержатся следующие значения: NetBiosDomainNameLogonName, NetBiosDomainName/LogonName, UserPrincipalName, DisplayName. Первые три значения формируются в связи с тем, что сервер Outlook Web Access на базе Windows 2003 Exchange Server считает, что вводимое в окне регистрации имя пользователя имеет вид NetBiosDomainNameLogonName, или NetBiosDomainName/LogonName, или UserPrincipalName.

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

Если формат журнального файла — W3C Extended Log File Format, то четвертая строка журнального файла содержит информацию о полях, записываемых в файл:

#Fields: date time s-ip cs-method cs-uri-stem

cs-uri-query s-port cs-username c-ip

cs(User-Agent) sc-status sc-substatus

sc-win32-status

Далее проверяется наличие нужных полей и запоминается позиция, на которой находится в строке журнального файла каждое из полей (см. листинг 3).

Теперь все готово для считывания необходимых нам значений полей из журнального файла. Считываем каждую следующую строку журнального файла в переменную str, и, если она не пустая и не начинается с символа #, формируем массив strArray = split(str, « «). Так как нам известны позиции каждого поля в строке, нам известны и значения самих полей. Например, значение поля cs-method будет равно strArray(fieldCsMethod).

Проверяем наличие условий cs-method = GET And cs-uristem =/exchange And cs-username <> «-». Наличие этих условий дает информацию об успешной или неуспешной авторизации пользователя, все остальные записи в журнальном файле опускаются. Если значение sc-status = 302, пользователь успешно авторизован, иначе имеется ошибка авторизации.

Значение поля cs-username (это будет strArray(fieldCsUserName)) последовательно сравнивается с первыми тремя из каждой четверки значений массива CSVArray(). При наличии совпадения четвертое значение из каждой четверки массива CSVArray() дает отображаемое имя пользователя strDisplayName, если совпадения не было — учетная запись пользователя с именем cs-username отсутствует, переменной strDisplayName присваивается значение: strDisplayName = «Пользователь не найден — ошибка в имени, или запись удалена».

Теперь остается только записать информацию в таблицу базы данных сервера SQL Server, что можно проиллюстрировать таким кодом:

Set con = CreateObject(«ADODB.Connection»)

con.Provider = «SQLOLEDB»

con.Properties(«Data Source»).Value = SQLServerName

con.Properties(«Initial Catalog»).Value = SQLDataBaseName

con.Properties(«Integrated Security»).Value = «SSPI»

con.Open

Set com = CreateObject(«ADODB.Command»)

com.ActiveConnection = con

В случае если аутентификация была успешной, строка запроса SQL будет иметь вид:

strDBQuery = «INSERT « & Trim(SQLTableName) &«(strDate,strTime,strUserName,StrDisplayName,strUserIP,strAuth,strHTTPCode) VALUES «

& «(?« & DateToWrite & «?,?» &

strArray(1) & «?,?» & strArray(fieldCsUserName) & «?,?» &

strDisplayName & «?,?» & strArray(fieldCIP) &

«?,?Успешно?,?» & strArray(fieldCsStatus) & «?)»

или в случае неудачной аутентификации:

strDBQuery = «INSERT « & Trim(SQLTableName) &

«(strDate,strTime,strUserName,StrDisplayName,strUserIP,strAuth,strHTTPCode) VALUES «

& «(?« & DateToWrite & «?,?» & strArray(1) & «?,?» & strArray(fieldCsUserName) &

«?,?» & strDisplayName & «?,?» & strArray(fieldCIP) & «?,?Ошибка?,?» & strArray(fieldCsStatus) & «?)»

Следует заметить, что переменная DateToWrite формируется следующим образом:

DateToWrite = Mid(strArray(0), 1, 4) & «.» &

Mid(strArray(0), 6, 2) & «.» & Mid(strArray(0), 9, 2),

Иначе говоря, это просто видоизмененное и приведенное к формату yyyy.mm.dd значение даты из поля date журнального файла. Использование такого формата обусловлено тем, что поле даты в таблице базы данных имеет тип varchar, т. е. представляет собой строку. При использовании даты в виде строки формата yyyy.mm.dd сортировка по значению даты работает корректно: по году, затем по месяцу и потом по дню.

Записываем информацию в базу данных и закрываем соединение с SQL Server:

com.CommandText = strDBQuery

Set rs = com.Execute

con.Close

После того как журнальный файл обработан, он перемещается в каталог с именем OWALogs & «Arc» и тем самым исключается из обработки при следующих запусках сценария. Если каталога OWALogs & «Arc» не существует, он создается.

По окончании работы в каталог, из которого запускался сценарий, записывается журнальный файл результатов работы сценария в формате HTML.

Сценарии ASP

Как уже отмечалось выше, информацию из базы данных SQL Server можно получать любым удобным способом. Сценарии ASP — это всего лишь один из возможных способов доступа к информации, которую записал в базу данных сценарий обработки журнальных файлов, поэтому подробно описывать их работу не имеет смысла, все желающие найдут сценарии ASP в каталоге с именем ASP.

Для удобства изменений сценариев при их создании соблюдается принцип максимально возможного разделения интерфейса, который отображается на стороне пользователя в Internet Explorer, с программным кодом, выполняемым на сервере. Поэтому сценарий состоит из парного количества файлов, за исключением файла параметров подключения к SQL Server 2000 — SQL.conf.

Перечень файлов сценария и их назначение:

  • default.asp обеспечивает внешний вид начальной страницы;
  • default.vb содержит код ASP, выполняющийся на начальной странице;
  • requestForm.asp формирует вид страницы запроса к базе данных;
  • requestForm.vb содержит код ASP, выполняющийся на странице запроса к базе данных;
  • showRequest.asp нужен для отображения запросов к базе данных;
  • showRequest.vb содержит код ASP, выполняющийся на странице отображения запросов к базе данных;
  • SQL.conf представляет собой просто перечень настроек подключения к серверу SQL Server.

Для создания базы данных на сервере SQL Server необходимы соответствующие разрешения. Режим аутентификации на сервере может быть SQL Server and Windows или Windows only, в сценарии заложен режим аутентификации Windows. С помощью SQL Server Enterprise Manager создаем базу данных, присваиваем ей имя — в сценарии это OWALog. Устанавливаем Recovery model — Simple, устанавливаем флажок Auto shrink (см. экран 1).

Экран 1. Настройка базы данных SQL Server для сценариев ASP

В базе данных создаем таблицу, в сценарии нашего примера имя таблицы — OWALogon; она имеет поля, показанные на экране 2. Таблицу можно создать как вручную, так и с помощью сценария SQL через Query Analyzer. Текст такого сценария на SQL для создания таблицы может быть таким, как в листинге 4.

Нужно иметь в виду, что учетная запись, от имени которой будет работать сценарий обработки журнальный файлов сервера Outlook Web Access, должна иметь разрешения на запись в созданную таблицу.

Экран 2. Структура таблицы OWALogon

Вероятнее всего, вы не захотите, чтобы информация о событиях аутентификации пользователей при использовании Outlook Web Access, отображаемая через Web-интерфейс, была доступна всем, поэтому лучше сразу создать в Active Directory группу доступа к содержащейся в ней информации. Этой группе необходимо предоставить разрешения доступа к базе данных db_datareader.

Последний аккорд

На сервере с установленным Internet Information Server следует создать виртуальный каталог и указать в качестве локального пути каталог, в котором находятся файлы сценария. Установите разрешения на доступ к каталогу — Read, разрешения для выполнения — Scripts only, запретите анонимный доступ и разрешите аутентификацию Windows. В разрешениях NTFS для локального каталога, в котором располагаются файлы сценария, удалите все разрешения и добавьте разрешения полного доступа для локальных администраторов сервера (или тому, кому требуется) и разрешение только на чтение для группы, о которой упоминалось выше. Вот и все, теперь только вы и допущенные вами пользователи смогут анализировать собранную информацию о доступе к серверу Outlook Web Access.

Григорий Антропов - главный специалист ООО «ЭКом АйТи». Занимается администрированием компьютерных сетей на базе Windows в компаниях, входящих в состав крупного холдинга. gantropov@hq.basel.ru