Параметры билета 0x40810010 код ошибки 0x18

Аудит событий регистрации пользователя

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

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

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

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

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

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

Windows 2000 генерирует событие с ID 673 еще в нескольких случаях. Во-первых, это событие часто имеет место при взаимодействии между системами; оно легко узнаваемо, так как в поле User Name помещается имя компьютера. Примером может служить ситуация, когда станция подключается к контроллеру домена для получения информации о групповой политике.

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

Послав запрос на билет TGT, компьютер пользователя сразу запрашивает билет доступа к службе, чтобы пользователь мог работать на данной машине. Экран 3 отображает фрагмент журнала безопасности, показывающий, что событие с ID 673 следует сразу за событием с ID 672. На Экране 4 приведены все поля события с ID 673. Просмотрев поля User Name, Service Name и Service с ID, можно сделать вывод, что пользователь Maggie зарегистрировалась на станции W2KPRO-LEFT. Поля User Domain и Service с ID содержат информацию о том, что и пользователь и компьютер принадлежат домену MTG. LOCAL.

Экран 3. Просмотр порядка появления событий.

На Экране 5 приведен еще один пример события с ID 673. В этом примере пользователь Maggie подключилась к удаленной системе TECRA с рабочей станции W2KPRO-LEFT. Имя удаленной системы TECRA показывают поля Service Name и Service с ID, но откуда известно имя рабочей станции W2KPRO-LEFT? Ответ подскажет значение поля Client Address: 10.0.0.81. Известно, что первое событие с ID 673, следующее за ID 672, всегда означает подключение пользователя к своей рабочей станции. Поскольку Maggie запрашивала билет TGT (событие с ID 672) с адреса 10.0.0.81, а затем билет доступа к службе (событие с ID 673) для подключения к W2KPRO-LEFT, значит, 10.0.0.81 является IP-адресом станции W2KPRO-LEFT. Последующие события с ID 673 (такие, как на Экране 5) показывают, что Maggie подключилась к ресурсам другой системы с того же самого адреса (т. е. 10.0.0.81).

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

Аудит событий Kerberos

Рассмотрим, какие типы событий записываются в журнал Windows 2000 при неудачных попытках аутентификации. Если во время регистрации с консоли рабочей станции вводится подлинное имя пользователя, но неверный пароль, то контроллер домена записывает в журнал событие с ID 675 (ошибка предварительной аутентификации) с кодом ошибки 24 (Failure Code 24) (см. Экран 6). Это очень важное сообщение, так как оно позволяет обнаруживать попытки подключения с неверными паролями. В сообщении указывается не только имя пользователя и имя домена, но и IP-адрес станции, с которой осуществлялась попытка несанкционированного доступа. Это огромный шаг вперед по сравнению с Win-dows NT, где в журнал записывались только имя пользователя и домен. Событие с ID 675 записывается еще и в том случае, если пользователь зарегистрировался на станции с одним именем, а затем пытался подключиться к серверу с другим. Например, он мог попробовать подключиться к сетевому диску от имени другого пользователя.

Иногда ошибка при регистрации в домене происходит не из-за неправильно введенного пароля, а из-за случайной опечатки при вводе имени пользователя или попытке подбора чужого имени. В этом случае (неправильное имя пользователя) Win-dows 2000 регистрирует событие с ID 676 с кодом ошибки 6. Это еще одно преимущество по сравнению с NT, где невозможно отличить отказ в регистрации из-за неверно введенного пароля от отказа из-за неверно введенного имени. Windows 2000 использует сообщение с ID 676 с различными кодами ошибок для контроля еще нескольких типов ошибок регистрации. Код ошибки 12 указывает на ошибку, возникающую при попытке регистрации в системе в часы, когда данному пользователю работать не разрешается. Код ошибки 23 означает, что срок действия пароля пользователя истек. Код ошибки 18 указывает на блокирование учетной записи в результате неудачных попыток подключения пользователя, завершения срока действия учетной записи или запрета администратора. Код ошибки 37 сообщает о том, что время на рабочей станции не синхронизировано со временем на контроллере домена и отличается на величину большую, чем это допустимо.

Бывают ситуации, когда пользователь получает от контроллера домена билет TGT, но не может получить билет доступа к службе. В этом случае Windows 2000 записывает событие с ID 677 (запрос на получение билета доступа к службе не удовлетворен) с тем или иным кодом ошибки, в зависимости от ситуации. Например, если пользователь со станции Windows 2000 Pro пытается подключиться к серверу NT, то в журнал записывается сообщение с ID 677 и кодом ошибки 7. На Экране 7 видно, что пользователь, зарегистрировавшийся на станции Windows 2000 Pro (IP-адрес 10.0.0.81) с именем Administrator, подключил сетевой диск сервера NT (т. е. Kramer), входящего в домен Windows 2000 (т. е. MTG. LOCAL). Сначала рабочая станция направила запрос контроллеру домена для получения билета Kerberos. Этот запрос не был удовлетворен, так как NT сервер не поддерживает протокол Kerberos. Поэтому в журнал контроллера записано сообщение с ID 677 с кодом 7. Эта ошибка не оказывает влияния на доступ пользователя к ресурсам, так как станция немедленно возвращается к использованию протокола NTLM.

События NTLM

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

Если аутентификация NTLM по каким-то причинам не может быть выполнена, то контроллер записывает в журнал событие с ID 681, как показано на Экране 9. О причинах неудачи можно судить по описанию кодов ошибок (см. Таблицу 1).

Новая категория аудита, Audit ac-count logon events, реализованная в Windows 2000, обеспечивает гораздо большую степень централизации аудита подключений пользователей. В системе появилась возможность отличать ошибки подключения, произошедшие из-за неверного ввода имени пользователя, от ошибок из-за ввода неверного пароля, а также вычислять по IP-адресу расположение станции-нарушителя. Тем не менее следует постоянно просматривать в журналах безопасности события категории Audit logon events («аудит подключений к системе»). Дело в том, что злоумышленники могут попытаться подключиться к системе, используя локальную учетную запись SAM, такую, как встроенная запись Administrator. Контроллер домена не фиксирует атаки, в которых используются локальные учетные записи. Просматривая события Audit logon events и Audit account logon events, можно следить за подключениями к рабочим станциям, серверам и контроллерам домена. В следующей статье из этой серии я расскажу о других категориях аудита, которые были изменены в Windows 2000.

В предыдущих выпусках

Это вторая статья Рэнди Франклина Смита из серии, посвященной журналу безопасности Windows 2000. Информацию о журнале безопасности Windows NT можно получить в предыдущей серии статей этого автора. Ниже приведен список статей обеих серий. Сами статьи можно найти на Web-сайте Windows 2000 Magazine по адресу: https://www. win2000mag. com.

Статьи, посвященные журналу безопасности Windows 2000

Статьи, посвященные журналу безопасности Windows NT

Ошибка CredSSP — Произошла ошибка при проверке подлинности

Windows

Всем добрый вечер, в декабре удаленно помогал одному из моих читателей с проблемой по которой, он оставил отзыв к статье — Не удается подключиться к удаленному рабочему столу и не смотря на то, что статья эта была написано аж в 2012 году, на нее до сих пор заходит большое кол-во пользователей и я не особо понимал причину такой популярности этой старой статьи до момента пока не стал разбираться с этой проблемой (ну по крайней мере я так думаю)) )!

Подсоединившись к его рабочему столу через TeamViewer и при подключение по RDP к серверу Windows 2012 у нас вылетела ошибка:

Произошла ошибка при проверке подлинности.
Указанная функция не поддерживается.
Причиной ошибки может быть исправление шифрования CredSSP
Дополнительные сведенья см. в статье https://go. microsoft. com/fwlink/?linkid=866660

An authentication error has occurred.
The function is not supported.
This could be due to CredSSP encryption oracle remediation.

Начал разбираться и вот что могу рассказать об этой ошибке:

Что такое CredSSP

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

У протокола CredSSP было три релиза-обновления

Поэтому когда мы подсоединяемся к серверу по RPD и вас отфутболивают, то тут две могут быть причины, либо на вашем компьютере поставились обновления либо на сервере были установлены накопительные обновления март — май 2018 года в которых убирается уязвимость в системе безопасности и при попытке подключения с непропатченной версией CredSSP у вас будет вылетать ошибка:

Давайте перейдем к

Варианты исправления ошибки CredSSP

Вариантов по устранению причины ошибки CredSSP несколько и мы пройдемся по каждой отдельно!

Установка последних обновлений

В котором вам предлагается скачать вручную обновление и поставить его на клиента/сервер

Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:

Отключить уведомления об ошибке шифрования CreedSSP

Но есть и более простой способ (но не безопасный) как это можно обойти если нет времени заниматься скачиванием и установкой! Этим способом мы просто отключаем это уведомление об ошибки и спокойно продолжаем работать по RDP

Отключение через групповые политики

Если же вам удобнее использовать редактор локальных групповых политик, то следуйте след инструкции:

Вот так мы и победили эту ошибку с подключением RPD к серверу! Так что будут вопрос, обязательно пишите и я постараюсь вам помочь!

Ошибка сервера 401: что это за ошибка и как ее исправить

Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:

Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.

Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя

При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:

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

Наиболее распространенной причиной появления ошибки с кодом 401 для рядового пользователя является ввод неверных данных при посещении определенного ресурса. В этом и других случаях нужно попробовать сделать следующее:

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

Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.

Устранение ошибки 401 администратором веб-ресурса

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

Где в поле /oldpage. html прописывается адрес проблемной страницы, а в https://site. com/newpage. html адрес страницы авторизации.

Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.

Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.

Дополнительная информация об ошибке с кодом 401

Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:

Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.

Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:

Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.

Источники:

Https://www. osp. ru/winitpro/2001/03/174731

Https://www. nibbl. ru/windows/oshibka-credssp-proizoshla-oshibka-pri-proverke-podlinnosti. html

Https://timeweb. com/ru/community/articles/oshibka-servera-401-chto-eto-za-oshibka-i-kak-ee-ispravit

У нас есть учетная запись домена, которая заблокирована через один из двух серверов. Встроенный аудит только говорит нам об этом (заблокирован от SERVER1, SERVER2).

Учетная запись блокируется в течение 5 минут, кажется, около 1 запроса в минуту.

Первоначально я попытался запустить procmon (из sysinternals), чтобы посмотреть, не появляется ли новый START PROCESS после того, как я разблокирую учетную запись. Ничего подозрительного не возникает. После запуска procmon на моей рабочей станции и перехода в оболочку UAC (conscent.exe) из стека кажется, что ntdll.dll а также rpct4.dll Вам звонят, когда вы пытаетесь авторизоваться против AD (не уверен).

Есть ли какой-то способ сузить, какой процесс вызывает запрос аутентификации для нашего DC? Это всегда один и тот же DC, поэтому мы знаем, что на этом сайте должен быть сервер. Я мог бы попытаться найти вызовы в Wireshark, но я не уверен, что это сузило бы, какой процесс фактически вызывает его.

Ни одна служба, ни сопоставление дисков, ни запланированные задачи не используют эту учетную запись домена, поэтому она должна быть чем-то, что хранит кредиты домена. На любом сервере нет открытых сеансов RDP с этой учетной записью домена (мы проверили).

Дальнейшие заметки

Да, на соответствующем контроллере домена включены проверки входа «Успех / Сбой» — события сбоев не регистрируются, пока учетная запись не будет заблокирована.

Дальнейшее копание показывает, что LSASS.exe делает KERBEROS позвоните в соответствующий ДЦ, как только учетная запись разблокирована. Ему предшествует (как правило) Java, который, кажется, называется vpxd.exe который является процессом vCenter. НО, когда я смотрю на другой «server2», где может (также) может произойти блокировка учетной записи, я никогда не вижу вызова lsass.exe и только процессы apache порождаются. Единственное отношение, которое они имеют, заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (сервер1 является операционной системой vSphere).

Ошибка на DC

Так что, похоже, все, что мне скажет AD, это то, что это ошибка Kerberos перед авторизацией. Я проверил и не было билетов с klist и сделал флеш в любом случае на всякий случай. До сих пор не знаю, что является причиной этой ошибки Kerberos.

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.

2013-08-07 23:00

5
ответов

События входа регистрируют процесс, пытающийся войти в систему. Включите неудачный аудит входа в систему (Параметры безопасности> Локальные политики> Политика аудита> Аудит событий входа в систему) в Локальной политике безопасности (secpol.msc), а затем найдите в журнале событий безопасности событие. Вы также можете включить его через групповую политику, если это предпочтительнее.

Будет раздел «Информация о процессе», в котором будет записан как путь к исполняемому файлу, так и идентификатор процесса.

Пример:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe


Mitch

08 авг ’13 в 00:00
2013-08-08 00:00

2013-08-08 00:00

Я нашел этот старый вопрос при исследовании другой проблемы, но для тех, у кого похожая проблема:

Код ошибки 0x18 означает, что учетная запись была уже отключена или заблокирована, когда клиент пытался пройти проверку подлинности.

Вам нужно найти тот же идентификатор события с кодом ошибки 0x24, который будет определять неудачные попытки входа в систему, которые привели к блокировке учетной записи. (Предполагается, что это происходит из-за неверного кэшированного пароля где-то.)

Затем вы можете посмотреть адрес клиента в этих событиях, чтобы увидеть, какая система передает неверные учетные данные. Оттуда вам придется выяснить, является ли это сервис со старым паролем, подключенным сетевым диском и т. Д.

Существует множество кодов ошибок, поэтому вы должны искать что-нибудь, кроме 0x18, чтобы определить причину блокировки учетной записи, если нет событий с кодами 0x24. Я считаю, что единственным типом сбоя, который приведет к блокировке, является 0x24 (неверный пароль), но я могу ошибаться.


DoubleD

16 мар ’18 в 18:40
2018-03-16 18:40

2018-03-16 18:40

Я провел много времени сегодня и выяснил причину. Я пошел не так, как надо — из перехваченной информации с помощью сетевого сниффера (идентификатор процесса ошибки Kerberos был 566 = lsass.exe). Позвольте мне обобщить информацию.

  1. Войдите на проблемный ПК, запустите PowerShell с повышенными правами.

  2. Включить аудит входа

    auditpol /set /subcategory:"logon" /failure:enable

  3. Проверьте источник

    Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

Если ты видишь:

Обрабатывать информацию:

Идентификатор вызывающего процесса: 0x140

Имя вызывающего процесса: C:\Windows\System32\services.exe

Это означает, что у вас запущен какой-то сервис из проблемной учетной записи со старым паролем


Alex

07 мар ’17 в 18:26
2017-03-07 18:26

2017-03-07 18:26

Это сверху заметки. Похоже, инициатор этого поста заявил в своем последнем комментарии. Java вызывает процесс vpxd.exe.

Дополнительные примечания Да, проверки входа в систему «Успех / Сбой» включены на соответствующем контроллере домена — события сбоев не регистрируются до тех пор, пока учетная запись не будет фактически заблокирована.

Дальнейшее копание показывает, что LSASS.exe делает соответствующий вызов KERBEROS DC, когда учетная запись разблокирована. Ему предшествует (как правило) java, которая, кажется, вызывается vpxd.exe, который является процессом vCenter. НО, когда я смотрю на другой «server2», где может (также) может произойти блокировка учетной записи, я никогда не вижу вызова lsass.exe, и порождаются только процессы apache. Единственное отношение, которое они имеют, заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (сервер1 является операционной системой vSphere).

2016-05-13 21:47

 

Windows 2003
Active Directory
более 100 учётных записей.
Распределены по различным департаментам.
Возникла проблема с одной учётной записью: Во время работы account блокируется — появляется галочка в AD account is block.
Какого вида должна быть запись в Евентах при блокировании?
Где ещё можно посмотреть логи, чтобы найти причину блокировки?

 

смотрите логи системы,
должно быть что то записано.

P.s. может кто то постояно не тот пароль набирает?

 

логи смотреть на контроллере домена, security log. будет видно когда и с какого компьютера были произведены попытки неправильно аутентифицироваться

 

Алекс М

Service Pack 1 стоит? В Windows XP без SP1 такое явление наблюдалось очень часто. Насколько помню и в Windows 2003 оно также присутствовало. Как я думаю, это ошибка LSASS — SP1 его обновляет, насколько помню, и данное явление пропадает.

 

Алекс М

Guest

#5

Это нравится:0Да/0Нет

24.03.2008 11:09:16

Цитата
VictorVG пишет:
Service Pack 1 стоит

нет — SP2.

Цитата
Michael пишет:
security log
Код
Authentication Ticket Request:
    User Name:      lika
    Supplied Realm Name:   domain
    User ID:         -
    Service Name:      [B]krbtgt[/B]/domain
    Service ID:      -
    Ticket Options:      0x40810010
    Result Code:      0x12
    Ticket Encryption Type:   -
    Pre-Authentication Type:   -
    Client Address:      192.168.0.152
    Certificate Issuer Name:   
    Certificate Serial Number:   
    Certificate Thumbprint:

выделенное смущает...
[I]Event ID 672[/I]

Logon Failure:
    Reason:      Account locked out
    User Name:   lika
    Domain:   domain
    Logon Type:   3
    Logon Process:   NtLmSsp 
    Authentication Package:   NTLM
    Workstation Name:   CPU10
    Caller User Name:   -
    Caller Domain:   -
    Caller Logon ID:   -
    Caller Process ID: -
    Transited Services: -
    Source Network Address:   192.168.0.152
    Source Port:   1608
[I]Event ID 539[/I]

Logon attempt by:   MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 Logon account:   lika
 Source Workstation:   CPU10
 Error Code:   0xC0000234
[I]Event ID 680[/I] это уже её попытка залогинется при блокированной учётке.
 

тогда вопрос по другому задам.
Как в АД для этого пользователя отключить блокировку вообще? Т.е. что бы учётка была включенна постоянно, не смотря на не правильный перебор паролей.

 

Michael

Guest

#7

Это нравится:0Да/0Нет

06.05.2008 20:28:34

Цитата
Алекс М пишет:
Как в АД для этого пользователя отключить блокировку вообще?

Это можно сделать группповыми политиками только в рамках всего домена

 

Editor

Сообщений: 1721
Баллов: 1738
Регистрация: 21.08.2003

Приведенные записи лога — уже постфактум блокировки (Kerberos result code 0x12 — ограничение на вход).
Надо искать неудачные поптыки аутентификации (Account Logon Event и Logon Events) с этой учетной записью.

Искать удобно EventCombMT из состава

http://www.microsoft.com/downloads/details.aspx?FamilyID=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

Зачастую такое происходит если пользователь «примапил» диск с паролем, а потом пароль сменился (99%), или создал задачу в планировкщике или созадл сервис «под собой». Т.е. надо найти с какой машины идет блокировка, а потом искать на ней причину.

 

Алекс М

Guest

#9

Это нравится:0Да/0Нет

07.05.2008 11:06:17

offtopic,
спасибо, буду искать и спользуя ссылку.
Но пароль не был сменён 100% — учётной записи не разрешено изменять пароль. Учётка блокируется при работе с рабочего компа и домашнего.
И ещё: вчера с ~19 по 03 часа ночи всё было Ок. А утром снова в блок.
Ищю 1% блокировки.
вот одна строчка из лога:

Код
675,AUDIT FAILURE,Security,Wed May 07 11:50:00 2008,NT AUTHORITY\SYSTEM,
     Ошибка предварительной проверки:     Имя пользователя: gena
     Код пользователя: %{S-1-5-21-73586283-1220945662-1801674531-1112}
     Имя службы: krbtgt/DOMAIN     Тип предварительной проверки: 0x2
     Код ошибки: 0x18     Адрес клиента:  192.168.0.1    
 

Алекс М

Guest

#10

Это нравится:0Да/0Нет

07.05.2008 12:24:37

Код
675,AUDIT FAILURE,Security,Wed May 07 11:50:00 2008,NT AUTHORITYSYSTEM, 
     Ошибка предварительной проверки:     Имя пользователя: gena 
     Код пользователя: %{S-1-5-21-73586283-1220945662-1801674531-1112} 
     Имя службы: krbtgt/DOMAIN     Тип предварительной проверки: 0x2 
     Код ошибки: 0x18     Адрес клиента:  192.168.0.1

 

Адрес клиента 192.168.0.1
сразу вопрос: клиент — в смысле кто авторизует?
этот IP принадлежит машине, на которой недавно установил вторичный AD.
Так же там DHCP сервер.

 

Editor

Сообщений: 1721
Баллов: 1738
Регистрация: 21.08.2003

Поищите ошибки в журналах машины  192.168.0.1

 

Алекс М

Guest

#12

Это нравится:0Да/0Нет

07.05.2008 14:35:16

Цитата
offtopic пишет:
192.168.0.1
Код
675,AUDIT FAILURE,Security,Wed May 07 14:23:59 2008,NT AUTHORITY\SYSTEM,
     Ошибка предварительной проверки:     Имя пользователя: gena
     Код пользователя: %{S-1-5-21-73586283-1220945662-1801674531-1112}
     Имя службы: krbtgt/DOMAIN     Тип предварительной проверки: 0x2
     Код ошибки: 0x18     Адрес клиента:  192.168.0.132

также есть «Адрес клиента:  127.0.0.1»
192.168.0.132 — это рабочая станция где работает человек  учёткой gena
вот ещё:

Код
672,AUDIT FAILURE,Security,Wed May 07 14:24:05 2008,NT AUTHORITY\SYSTEM,
     Запрос билета проверки подлинности:     Имя пользователя: Gena
     Предоставленное имя сферы: DOMAIN     Код пользователя: -
     Имя службы: krbtgt/DOMAIN     Код службы: -
     Параметры билета: 0x40810010     Код результата:  0x12     Тип шифрования билета: -
     Тип предварительной проверки: -     Адрес клиента:  192.168.0.132

Аудит событий регистрации пользователя

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

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

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

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

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

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

Windows 2000 генерирует событие с ID 673 еще в нескольких случаях. Во-первых, это событие часто имеет место при взаимодействии между системами; оно легко узнаваемо, так как в поле User Name помещается имя компьютера. Примером может служить ситуация, когда станция подключается к контроллеру домена для получения информации о групповой политике.

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

Послав запрос на билет TGT, компьютер пользователя сразу запрашивает билет доступа к службе, чтобы пользователь мог работать на данной машине. Экран 3 отображает фрагмент журнала безопасности, показывающий, что событие с ID 673 следует сразу за событием с ID 672. На Экране 4 приведены все поля события с ID 673. Просмотрев поля User Name, Service Name и Service с ID, можно сделать вывод, что пользователь Maggie зарегистрировалась на станции W2KPRO-LEFT. Поля User Domain и Service с ID содержат информацию о том, что и пользователь и компьютер принадлежат домену MTG. LOCAL.

Экран 3. Просмотр порядка появления событий.

На Экране 5 приведен еще один пример события с ID 673. В этом примере пользователь Maggie подключилась к удаленной системе TECRA с рабочей станции W2KPRO-LEFT. Имя удаленной системы TECRA показывают поля Service Name и Service с ID, но откуда известно имя рабочей станции W2KPRO-LEFT? Ответ подскажет значение поля Client Address: 10.0.0.81. Известно, что первое событие с ID 673, следующее за ID 672, всегда означает подключение пользователя к своей рабочей станции. Поскольку Maggie запрашивала билет TGT (событие с ID 672) с адреса 10.0.0.81, а затем билет доступа к службе (событие с ID 673) для подключения к W2KPRO-LEFT, значит, 10.0.0.81 является IP-адресом станции W2KPRO-LEFT. Последующие события с ID 673 (такие, как на Экране 5) показывают, что Maggie подключилась к ресурсам другой системы с того же самого адреса (т. е. 10.0.0.81).

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

Аудит событий Kerberos

Рассмотрим, какие типы событий записываются в журнал Windows 2000 при неудачных попытках аутентификации. Если во время регистрации с консоли рабочей станции вводится подлинное имя пользователя, но неверный пароль, то контроллер домена записывает в журнал событие с ID 675 (ошибка предварительной аутентификации) с кодом ошибки 24 (Failure Code 24) (см. Экран 6). Это очень важное сообщение, так как оно позволяет обнаруживать попытки подключения с неверными паролями. В сообщении указывается не только имя пользователя и имя домена, но и IP-адрес станции, с которой осуществлялась попытка несанкционированного доступа. Это огромный шаг вперед по сравнению с Win-dows NT, где в журнал записывались только имя пользователя и домен. Событие с ID 675 записывается еще и в том случае, если пользователь зарегистрировался на станции с одним именем, а затем пытался подключиться к серверу с другим. Например, он мог попробовать подключиться к сетевому диску от имени другого пользователя.

Иногда ошибка при регистрации в домене происходит не из-за неправильно введенного пароля, а из-за случайной опечатки при вводе имени пользователя или попытке подбора чужого имени. В этом случае (неправильное имя пользователя) Win-dows 2000 регистрирует событие с ID 676 с кодом ошибки 6. Это еще одно преимущество по сравнению с NT, где невозможно отличить отказ в регистрации из-за неверно введенного пароля от отказа из-за неверно введенного имени. Windows 2000 использует сообщение с ID 676 с различными кодами ошибок для контроля еще нескольких типов ошибок регистрации. Код ошибки 12 указывает на ошибку, возникающую при попытке регистрации в системе в часы, когда данному пользователю работать не разрешается. Код ошибки 23 означает, что срок действия пароля пользователя истек. Код ошибки 18 указывает на блокирование учетной записи в результате неудачных попыток подключения пользователя, завершения срока действия учетной записи или запрета администратора. Код ошибки 37 сообщает о том, что время на рабочей станции не синхронизировано со временем на контроллере домена и отличается на величину большую, чем это допустимо.

Бывают ситуации, когда пользователь получает от контроллера домена билет TGT, но не может получить билет доступа к службе. В этом случае Windows 2000 записывает событие с ID 677 (запрос на получение билета доступа к службе не удовлетворен) с тем или иным кодом ошибки, в зависимости от ситуации. Например, если пользователь со станции Windows 2000 Pro пытается подключиться к серверу NT, то в журнал записывается сообщение с ID 677 и кодом ошибки 7. На Экране 7 видно, что пользователь, зарегистрировавшийся на станции Windows 2000 Pro (IP-адрес 10.0.0.81) с именем Administrator, подключил сетевой диск сервера NT (т. е. Kramer), входящего в домен Windows 2000 (т. е. MTG. LOCAL). Сначала рабочая станция направила запрос контроллеру домена для получения билета Kerberos. Этот запрос не был удовлетворен, так как NT сервер не поддерживает протокол Kerberos. Поэтому в журнал контроллера записано сообщение с ID 677 с кодом 7. Эта ошибка не оказывает влияния на доступ пользователя к ресурсам, так как станция немедленно возвращается к использованию протокола NTLM.

События NTLM

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

Если аутентификация NTLM по каким-то причинам не может быть выполнена, то контроллер записывает в журнал событие с ID 681, как показано на Экране 9. О причинах неудачи можно судить по описанию кодов ошибок (см. Таблицу 1).

Новая категория аудита, Audit ac-count logon events, реализованная в Windows 2000, обеспечивает гораздо большую степень централизации аудита подключений пользователей. В системе появилась возможность отличать ошибки подключения, произошедшие из-за неверного ввода имени пользователя, от ошибок из-за ввода неверного пароля, а также вычислять по IP-адресу расположение станции-нарушителя. Тем не менее следует постоянно просматривать в журналах безопасности события категории Audit logon events («аудит подключений к системе»). Дело в том, что злоумышленники могут попытаться подключиться к системе, используя локальную учетную запись SAM, такую, как встроенная запись Administrator. Контроллер домена не фиксирует атаки, в которых используются локальные учетные записи. Просматривая события Audit logon events и Audit account logon events, можно следить за подключениями к рабочим станциям, серверам и контроллерам домена. В следующей статье из этой серии я расскажу о других категориях аудита, которые были изменены в Windows 2000.

В предыдущих выпусках

Это вторая статья Рэнди Франклина Смита из серии, посвященной журналу безопасности Windows 2000. Информацию о журнале безопасности Windows NT можно получить в предыдущей серии статей этого автора. Ниже приведен список статей обеих серий. Сами статьи можно найти на Web-сайте Windows 2000 Magazine по адресу: https://www. win2000mag. com.

Статьи, посвященные журналу безопасности Windows 2000

Статьи, посвященные журналу безопасности Windows NT

Ошибка CredSSP — Произошла ошибка при проверке подлинности

Windows

Всем добрый вечер, в декабре удаленно помогал одному из моих читателей с проблемой по которой, он оставил отзыв к статье — Не удается подключиться к удаленному рабочему столу и не смотря на то, что статья эта была написано аж в 2012 году, на нее до сих пор заходит большое кол-во пользователей и я не особо понимал причину такой популярности этой старой статьи до момента пока не стал разбираться с этой проблемой (ну по крайней мере я так думаю)) )!

Подсоединившись к его рабочему столу через TeamViewer и при подключение по RDP к серверу Windows 2012 у нас вылетела ошибка:

Произошла ошибка при проверке подлинности.
Указанная функция не поддерживается.
Причиной ошибки может быть исправление шифрования CredSSP
Дополнительные сведенья см. в статье https://go. microsoft. com/fwlink/?linkid=866660

An authentication error has occurred.
The function is not supported.
This could be due to CredSSP encryption oracle remediation.

Начал разбираться и вот что могу рассказать об этой ошибке:

Что такое CredSSP

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

У протокола CredSSP было три релиза-обновления

Поэтому когда мы подсоединяемся к серверу по RPD и вас отфутболивают, то тут две могут быть причины, либо на вашем компьютере поставились обновления либо на сервере были установлены накопительные обновления март — май 2018 года в которых убирается уязвимость в системе безопасности и при попытке подключения с непропатченной версией CredSSP у вас будет вылетать ошибка:

Давайте перейдем к

Варианты исправления ошибки CredSSP

Вариантов по устранению причины ошибки CredSSP несколько и мы пройдемся по каждой отдельно!

Установка последних обновлений

В котором вам предлагается скачать вручную обновление и поставить его на клиента/сервер

Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:

Отключить уведомления об ошибке шифрования CreedSSP

Но есть и более простой способ (но не безопасный) как это можно обойти если нет времени заниматься скачиванием и установкой! Этим способом мы просто отключаем это уведомление об ошибки и спокойно продолжаем работать по RDP

Отключение через групповые политики

Если же вам удобнее использовать редактор локальных групповых политик, то следуйте след инструкции:

Вот так мы и победили эту ошибку с подключением RPD к серверу! Так что будут вопрос, обязательно пишите и я постараюсь вам помочь!

Ошибка сервера 401: что это за ошибка и как ее исправить

Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:

Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.

Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя

При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:

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

Наиболее распространенной причиной появления ошибки с кодом 401 для рядового пользователя является ввод неверных данных при посещении определенного ресурса. В этом и других случаях нужно попробовать сделать следующее:

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

Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.

Устранение ошибки 401 администратором веб-ресурса

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

Где в поле /oldpage. html прописывается адрес проблемной страницы, а в https://site. com/newpage. html адрес страницы авторизации.

Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.

Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.

Дополнительная информация об ошибке с кодом 401

Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:

Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.

Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:

Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.

Источники:

Https://www. osp. ru/winitpro/2001/03/174731

Https://www. nibbl. ru/windows/oshibka-credssp-proizoshla-oshibka-pri-proverke-podlinnosti. html

Https://timeweb. com/ru/community/articles/oshibka-servera-401-chto-eto-za-oshibka-i-kak-ee-ispravit

Hi,

Can you please help me to find out the reason of following issue.

In our domain after enabling audit we found that huge numbers(around 50k) of Kerberos pre-authentication failed(4771) security failure events are generating in DCs. If any one can explain why this events are generating so frequently. However I found no account lockout has happened. One sample event is as follows.

«

Log Name:     Security

Source:       Microsoft-Windows-Security-Auditing

Date:         2019-08-05 09:40:05

Event ID:     4771

Task Category: Kerberos Authentication Service

Level:        Information

Keywords:     Audit Failure

User:         N/A

Computer:     DC.domain.com

Description:

Kerberos pre-authentication failed.

Account Information:

Security ID: domain\user

Account Name: user

Service Information:

Service Name: krbtgt/domain.com

Network Information:

Client Address: ::ffff:IP_address

Client Port: 57415

Additional Information:

Ticket Options: 0x40810010

Failure Code: 0x18

Pre-Authentication Type: 2

Certificate Information:

Certificate Issuer Name:

Certificate Serial Number:

Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication.

Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
«

I can see that in few cases more than 100 events generated in 30 mins for one user. But no account lockout happened of that user because the failure code is 0x18.

I have checked that account lockout policy is also not satisfying for account unlocking. policy is as below.

Account Policies/Account Lockout Policy

Account lockout duration 0 minutes  
Account lockout threshold 10 invalid logon attempts  
Reset account lockout counter after 30 minutes  

The reported users may use hand-held devices(certificate based) and can use multiple machines. I found the time difference between DC and End computers used by those affected users.

Please anyone can help me to investigate the root cause of huge numbers of logon failure/4771 events in our domain.

Понравилась статья? Поделить с друзьями:
  • Параметры system settings exe системная ошибка
  • Параметр задан неверно код ошибки 0x80070057
  • Параметр modify file вызвал системную ошибку 665
  • Параллельная парковка ошибки как исправить
  • Параллельные синтаксические конструкции ошибки