Аудит входа в систему с доменной учетной записью

Категория Аудит событий входа в систему (Audit logon events), как уже говорилось выше), используется для сбора данных на той локальной системе, к которой произошло подключение. Однако следить за большим количеством сетевых подключений, перебирая одну систему за другой, крайне неудобно.

На помощь приходит новая категория Audit account logon events («аудит событий регистрации с учетной записью пользователя»), использущая контроллеры доменов Windows как основное место сбора сообщений о событиях аутентификации.

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

Следить за такими событиями можно при помощи оснастки Domain Controller Security Policy консоли управления MMC контроллера домена. Это расширение использует параметры объекта Default Domain Controller Group Policy Object (GPO), которые называются Security Settings. В свою очередь, GPO входит в организационную единицу Domain Controllers, а организационная единица – в состав AD. Чтобы включить аудит, следует в консоли выбрать Local Policies\Audit Policy, перейти на правую панель, щелкнуть правой кнопкой мыши на Audit account logon events и выбрать Security. Откроется диалоговое окно Security Policy Setting. Для включения аудита нужно отметить флажки Success и Failure, затем сохранить изменения.

Windows начиная с Windows 2000 может использовать протоколы аутентификации Kerberos (только в пределах домена) и Windows NT LAN Manager (NTLM) (для аутентификации компьютеров, не входящих в домен) для обработки запросов на подключение к системе. Для разных протоколов аутентификации в журнале аудита генерируются разные типы сообщений.

Kerberos используется при локальном подключении к рабочей станции Windows или сетевом подключении пользователя домена с рабочей станции Windows к серверу Windows. В этом случае на контроллере домена ведется запись событий, специфичных для Kerberos.

Если пользователь локально или удаленно подключается к системе NT или к серверу со станции NT, не включенной в домен, то применяется NTLM, и ведется запись событий, характерная для этого протокола.

Аудит успешных событий Kerberos

Протокол аутентификации Kerberos применяет шифрованные билеты, tickets (с записанными временными метками), для проверки возможности входа в систему. Чтобы предоставить доступ даже к локальной системе, Windows сначала запрашивает у контроллера домена билет доступа к службе (service ticket). Он содержит информацию, подтверждающую права пользователя на доступ к системе. Но прежде, чем будет получен билет доступа к службе, выполняется аутентификация пользователя на контроллере домена и затем выдается билет на сеанс работы, ticket-granting ticket (TGT). Пароль пользователя проверяется контроллером домена только один раз. Это происходит на ранней стадии подключения к рабочей станции, когда станция запрашивает TGT для пользователя. После того как билет TGT получен и пользователю требуется подключаться к различным сетевым службам (например, файловым серверам, серверу SQL, серверу Exchange), рабочая станция использует тот же билет TGT при формировании каждого нового запроса. В этом отличие TGT от билета доступа к службе, который запрашивается всякий раз при подключении пользователя к сетевым службам. Удачные и неудачные попытки запросов билетов TGT и доступа к службе фиксируются в журнале Windows 2000 с различными идентификаторами с ID.

Каждый раз, когда пользователь включает компьютер, вводит свое имя в домене и пароль, станция запрашивает TGT у ближайшего контроллера домена. Если имя и пароль признаны корректными, проводится проверка полномочий пользователя, после чего контроллер выдает TGT, и в журнал записывается событие с ID 672 (аутентификация проведена успешно). Поле User для этого события (и всех аналогичных событий категории Audit account logon event) не содержит реального имени пользователя; поле всегда читается как SYSTEM. Следует обратить внимание на поля User Name и Supplied Realm Name, которые отображают имя пользователя и его DNS-суффикс. При создании учетной записи можно использовать полное DNS-имя или корневое имя дерева домена в формате domain\username. Поле User с ID выводит то же имя в стиле NT (т. е. NetBIOS имя домена, отделенное от имени пользователя знаком «обратный слеш»). Поле Service Name указывает имя службы, на доступ к которой контроллер домена выдал билет. Если это самое первое обращение рабочей станции к контроллеру, то в поле находится имя службы krbtgt (т. е. квитанция Kerberos).

Поле Client Address указывает IP-адрес станции, с которой пользователь пытался зарегистрироваться в домене. Все события Kerberos, включая неудачные попытки подключения, содержат этот IP-адрес. Эта информация бесценна. В NT можно узнать имя системы, осуществлявшей неудачные попытки подключения, но нельзя определить, из каких сегментов сети предпринимались эти попытки. Преимущество Windows 2000 состоит не только в централизации ведения журналов на контроллерах доменов, но и в том, что можно определить, откуда пытались подключиться к домену.

Существуют и другие примеры события с ID 672, когда компьютеру необходима авторизация в домене. Обычно это происходит в момент загрузки рабочей станции или перезагрузки сервера. Компьютер должен пройти авторизацию на контроллере домена, прежде чем он получит доступ к данным групповой политики или сможет зарегистрировать свое доменное имя. В этом случае поля User Name и User с ID содержат имя компьютера. К имени компьютера добавлен знак $, что отличает его от имени пользователя.

Событие с ID 672 позволяет контролировать первичные подключения к домену при помощи процедуры получения билета TGT, а событие с ID 673 контролирует доступ к сетевым службам при помощи процедуры получения билета доступа к службе. Например, если пользователь отображает диск на каталог файлового сервера или подключается к другим ресурсам удаленной системы (например, реестру, файлу журнала, SAM), то система запрашивает билет доступа к службе, и на контроллере домена генерируется событие с ID 673.

Важно понять, как связаны между собой события с ID 672 и с ID 673. Выдача контроллером билета TGT (событие с ID 672) еще не означает, что пользователю разрешен доступ к какой-либо системе; TGT подтверждает подлинность учетной записи пользователя и дает возможность его последующей авторизации при запросе билета доступа к службам (событие с ID 673) для подключения к различным системам. Послав запрос на билет TGT, компьютер пользователя сразу запрашивает билет доступа к службе, чтобы пользователь мог работать на данной машине.

Для предотвращения атак Kerberos ограничивает срок действия билета, полученного от контроллера домена. Если время истекает, а пользователь все еще подключен к ресурсам, то Windows автоматически запрашивает контроллер домена и обновляет билет. При обновлении билета в журнал записывается событие с ID 674.

Аудит неудачных событий Kerberos

Рассмотрим, какие типы событий записываются в журнал Windows при неудачных попытках аутентификации.

Если во время регистрации с консоли рабочей станции вводится подлинное имя пользователя, но неверный пароль, то контроллер домена записывает в журнал событие с ID 675 (Pre-authentication failed - ошибка предварительной аутентификации) с кодом ошибки 24 (0х18)(Failure Code 24). Это очень важное сообщение, так как оно позволяет обнаруживать попытки подключения с неверными паролями. В сообщении указывается не только имя пользователя и имя домена, но и IP-адрес станции, с которой осуществлялась попытка несанкционированного доступа.

Событие с ID 675 записывается еще и в том случае, если пользователь зарегистрировался на станции с одним именем, а затем пытался подключиться к серверу с другим. Например, он мог попробовать подключиться к сетевому диску от имени другого пользователя.

Ошибка при регистрации в домене может также происходить не из-за неправильно введенного пароля, а из-за случайной опечатки при вводе имени пользователя или попытке подбора чужого имени. В этом случае (неправильное имя пользователя) Windows регистрирует событие с ID 676 с кодом ошибки 6 (см. рис ниже).

Windows использует сообщение с ID 676 с различными кодами ошибок для контроля еще нескольких типов ошибок регистрации:

Аутентификация Kerberos. Коды ошибок событий с ID 675 и с ID 676

Код ошибки Причина

0x6 Указанное имя пользователя не существует

0x12 Ограничения по рабочей станции; ограничения на время регистрации; учетная запись отключена, срок ее действия истек или учетная запись заблокирована

0x17 Срок действия пароля истек

0x18 Неверно указанный пароль при правильно заданном имени пользователя

0x25 Часы на рабочей станции слишком сильно отстают от часов контроллера домена

Бывают ситуации, когда пользователь получает от контроллера домена билет TGT, но не может получить билет доступа к службе. В этом случае Windows записывает событие с ID 677 (запрос на получение билета доступа к службе не удовлетворен) с тем или иным кодом ошибки, в зависимости от ситуации. Например, если пользователь со станции Windows пытается подключиться к серверу, то в журнал записывается сообщение с ID 677 и кодом ошибки 7.

События NTLM

После того как контроллер домена успешно аутентифицировал пользователя, в журнал записывается событие с ID 680. Подобно событию Kerberos с ID 673, в котором указывается имя пользователя и IP-адрес станции, в событии с ID 680 указывается имя пользователя и имя станции, откуда поступил запрос на подключение. Так как NTLM может функционировать поверх TCP/IP, NetBEUI и IPX, то Windows записывает в журнал имя системы, а не ее IP-адрес. Если аутентификация NTLM по каким-то причинам не может быть выполнена, то контроллер записывает в журнал событие с ID 681. О причинах неудачи можно судить по описанию кодов ошибок (см. рис. и таблицу ниже).

Аутентификация NTLM Коды ошибок события с ID 680 и 681.

Код ошибки Причина

3221225572 Регистрация с неверной учетной записью пользователя

3221225578 Регистрация с неверным паролем

3221225583 Пользователь регистрируется в запрещенное время

3221225584 Пользователь регистрируется с запрещенной рабочей станции

3221225585 Пользователь регистрируется с паролем, срок действия которого истек

3221225586 Пользователь применяет учетную запись, заблокированную администратором

3221225875 Пользователь применяет учетную запись, срок действия которой истек

3221226020 Пользователь регистрируется с флагом Change Password at Next Logon

3221226036 Пользователь задействует заблокированную учетную запись

Замечание 1: На контроллерах домена Windows 2003 отслеживать события с ID 681 не нужно. В XP и более поздних версиях Windows разработчики Microsoft заменили событие с ID 681 другим, с ID 680. Windows 2000 использует событие с ID 680 только для сообщений об успешно проведенной аутентификации. В XP и более поздних версиях событие с ID 680 может означать успешную или неуспешную аутентификацию, что распознается по типу события — Failure Audit или Success Audit.

Замечание 2: Событие с ID 680 или событие с ID 681 с кодами сбоя означают, что по крайней мере один компьютер, участвующий в процедуре регистрации, — это станция не с Windows 2000 или выше, а с более ранней версией Windows или же компьютер из домена, с которым не установлены доверительные отношения. Компьютер с предыдущей версией Windows может быть как рабочей станцией, так и сервером, который является членом домена (т. е. пользователь рабочей станции Windows подключается к автономному серверу с более ранней версией, чем Windows 2000, с доменной учетной записью). Идентифицировать рабочую станцию можно по IP-адресу клиента в описании события с ID 675 или по имени рабочей станции в событии с ID 680 или событии с ID 681.

Если администратор имеет обыкновение переименовывать группу Administrator для защиты от нападения хакеров, следует наблюдать за событием с ID 681 с кодом ошибки 3221225 572 и событием с ID 676 с кодом сбоя 6, в которых в качестве имени пользователя фигурирует Administrator.

Мониторинг событий с ID 675 и ID 676, как и неудачные события с ID 680 или событие с ID 681 на серверах DC, дает полную информацию обо всех случаях неудачной регистрации с использованием доменных учетных записей, однако при этом ничего не известно о попытках регистрации на серверах — членах домена через локальную базу учетных записей SAM. Во время атак злоумышленники часто используют локальные учетные записи, чтобы попытаться получить доступ к компьютеру, поскольку локальные учетные записи сложнее поддаются мониторингу и управлению, а локальные пароли зачастую легко «взламываются». Чтобы выполнить мониторинг такой активности, нужно включить политику Audit account logon events на серверах, которые являются членами домена, и наблюдать за событиями с ID 681, появление которых означает, что кто-то пытается зарегистрироваться на сервере при помощи определенной учетной записи. Серверы — члены домена никогда не записывают события Kerberos, поскольку учетные записи локальной SAM всегда работают с аутентификацией NTLM. Важно убедиться, что системные администраторы используют оптимальные технические приемы и избегают применения локальных учетных записей вместо доменных. После этого нужно настроить мониторинг успешно проведенной регистрации на серверах с использованием локальной SAM (событие с ID 681). Если точно известно, что администраторы не применяют локальные учетные записи, подобная активность должна рассматриваться как подозрительная.

Возможно, имеет смысл отключить категорию Audit logon events на серверах — членах домена, поскольку эта политика генерирует события как при обращении к локальной SAM, так и при регистрации с использованием доменных учетных записей, но без видимого различия между ними, что сильно «засоряет» события политики Audit account logon events. Единственная польза включения политики Audit logon events на серверах заключается в том, что она дает возможность отличить локальную регистрацию от подключений по сети.