События входа в аккаунт с ошибкой

У нас есть сервер под управлением SQL 2008 R1. У нас есть веб-сервер в демилитаризованной зоне, который через брандмауэр подключается к серверу SQL и выполняет отчеты служб отчетов SQL с использованием учетной записи пользователя домена.

На сервере SQL в журнале событий выполнялся аудит неудачных событий "Вход в учетную запись" (код события 680, код 0xC0000064) для этого пользователя домена. Однако для каждого из этих событий отказа существует успешное событие входа / выхода из системы (идентификатор события 540) для той же учетной записи домена. Следует отметить, что имя пользователя в событиях входа в учетную запись указывается как UPN username@domain.com), а имя пользователя в событиях входа в систему / выхода из системы указывается как DOMAIN\Username. Эти события должны быть связаны с SSRS, поскольку это единственное соединение, которое должно использовать данную учетную запись.

Кроме того, при мониторинге нашего контроллера домена каждый раз, когда появляется одно из событий входа в учетную запись, загрузка ЦП контроллера домена возрастает до 80% или выше. Я не уверен, что оба связаны.

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

1. Почему мой SQL-сервер регистрирует события входа в учетную запись, если они должны быть событиями контроллера домена?
2. Почему имя участника-пользователя указано в одном событии, а формат DOMAIN \ Username указан в другом событии?
3. Я не замечаю каких-либо нарушений в работе моего приложения, поэтому неудачные входы в систему не влияют на него. С чего бы это?

ОБНОВИТЬ:

В нашей интрасети также работает одно и то же веб-приложение. Я только что заметил, что это приложение не приводит к тому, что эти самые события генерируются. Когда это приложение подключается к SSRS, оно регистрирует пару успешных событий входа / выхода из системы, но вообще никаких событий входа в систему. Следовательно, это связано с тем, что другой сервер находится в демилитаризованной зоне. Я также заметил, что события, генерируемые соединениями интрасети, показывают Kerbe ros как используемый метод аутентификации. Однако успешные события входа в систему / выхода из системы, созданные из подключений DMZ, указывают NTLM.