Параметры билета 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

Как исправить код ошибки 0x81000019 в Windows 10?

Несколько пользователей Window 10 сталкивались с 0x81000019 ошибка код при попытке сделать резервную копию Window 10. После нескольких минут обработки этот код ошибки появляется на экране вместе с соо

Содержание:

Несколько пользователей Windows 10 сталкивались с 0x81000019 ошибка код при попытке сделать резервную копию Windows 10. После нескольких минут обработки этот код ошибки появляется на экране вместе с сообщением об ошибке ‘Не удалось создать теневую копию‘. Эта ошибка часто связана с журналами событий VSS и SPP. Как оказалось, проблема, похоже, исключительно в Windows 10.

Что вызывает ошибку резервного копирования Windows 0x81000019?

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

Если в настоящее время вы столкнулись с той же проблемой и ищете способ ее решения, приведенные ниже шаги в конечном итоге позволят вам исправить 0x81000019 ошибка код навсегда. Имейте в виду, что каждое из возможных исправлений, упомянутых ниже, подтверждено как минимум одним затронутым пользователем.

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

Метод 1: увеличение системного раздела

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

Некоторые пользователи подтвердили, что им удалось решить эту проблему, используя стороннее приложение, чтобы увеличить системный зарезервированный раздел до более 500 МБ, взяв место на C или другом обычном диске.

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

Примечание: Мы используем бесплатную версию Partition Wizard, но не стесняйтесь использовать любой другой продукт, способный сделать это, если вам это удобнее.

Если вы все еще сталкиваетесь с 0x81000019 код ошибки, перейдите к следующему способу ниже.

Метод 2: установка службы теневого копирования тома на АВТОМАТИЧЕСКИЙ

Другая потенциальная причина, которая может вызвать 0x81000019 код ошибки является неправильным экземпляром Теневая копия тома служба (обычно называемая службой VSS). В большинстве случаев процедура резервного копирования не может быть завершена, поскольку для службы VSS установлено значение Руководство.

Несколько затронутых пользователей, которые также изо всех сил пытались решить эту проблему, сообщили, что им наконец удалось решить проблему, изменив тип состояния теневого копирования тома на автоматический. Большинство пользователей сообщили, что после этого они смогли завершить процедуру резервного копирования, не столкнувшись с 0x81000019 код ошибки.

Вот краткое руководство по изменению типа статуса службы теневого копирования тома на автоматический:

Если вы все еще сталкиваетесь с тем же 0x81000019 код ошибки при попытке повторить действие, перейдите к следующему способу ниже.

Метод 3: отключите сторонний пакет AV (если применимо)

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

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

Если вы уже следовали этому методу безуспешно или это было неприменимо, поскольку вы не используете сторонний пакет AV, перейдите к следующему потенциальному исправлению ниже.

Метод 4: запуск сканирования DISM и SFC

Оказывается, эта конкретная проблема также может возникнуть из-за какого-то повреждения системного файла. Об этом постоянно сообщали несколько разных пользователей Windows 10, которые намекали, что компонент резервного копирования может быть заблокирован поврежденными данными, присутствующими в критических папках.

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

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

Вот краткое руководство по запуску сканирований SFC и DISM из командной строки с повышенными привилегиями:

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

DISM / Онлайн / Очистка-Образ / RestoreHealth

Примечание: Важно помнить, что DISM требует постоянного подключения к Интернету. Это очень важно, поскольку утилиты заимствуют WU (компонент Windows) для загрузки работоспособных копий, которые позже будут использоваться для замены поврежденных экземпляров. В связи с этим вам необходимо убедиться, что ваше сетевое соединение не прерывается во время этого процесса.

Если то же самое 0x81000019 код ошибки все еще возникает, перейдите к следующему способу ниже.

Метод 5: Выполните ремонтную установку / чистую установку

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

Когда дело доходит до этого, у вас есть два пути вперед:

Не стесняйтесь следовать тому методу, который ближе к тому, что вы задумали.