Это - символьная ссылка, но у Вас есть аргументы ln
назад.
ln -s /storage/thumbs thumbs
Вы также используете неправильную команду.
Logon events record the process attempting logon. Enable failed logon auditing (Security Settings > Local Policies > Audit Policy > Audit Logon Events) in the Local Security Policy (secpol.msc) then look in the security event log for an event. You can also enable it via Group Policy, if that would be preferable.
There will be a Process Information section which records both the executable path and process ID.
Example:
Process Information:
Process ID: 0x2a4
Process Name: C:\Windows\System32\services.exe
Это из примечаний выше. Похоже, инициатор этого поста заявил в своем последнем комментарии. Java вызывает процесс vpxd.exe.
Дополнительные примечания Да, аудит входа в систему «Успех / сбой» включен на рассматриваемом контроллере домена - события сбоя не регистрируются до тех пор, пока учетная запись не будет фактически заблокирована.
Дальнейшее копание показывает, что LSASS.exe выполняет вызов KERBEROS на соответствующий контроллер домена после того, как аккаунт будет разблокирован. Ему предшествует (обычно) java, который, кажется, вызывается vpxd.exe, который является процессом vCenter. НО, когда я смотрю на другой «server2», где может (также) произойти блокировка учетной записи, я никогда не вижу вызова lsass.exe, и создаются только процессы apache. Единственная связь между ними заключается в том, что SERVER2 является частью кластера vSphere SERVER1 (server1 является ОС vSphere).
Сегодня я провёл много времени и выяснил первопричину. Я пошел не тем путем - из перехваченной информации с помощью сетевого сниффера (id процесса ошибки kerberos был 566 = lsass.exe). Позвольте мне подытожить информацию.
Войдите на проблемный ПК, запустить оболочку с повышенными правами
Включить вход аудита
auditpol /set /subcategory: "logon" /failure:enable
Проверка источника
Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]". -MaxEvents 2 | fl
Если вы видите:
Информация о процессе:
Caller Process ID: 0x140
Имя процесса вызывающего абонента: C:\Windows\System32\services.exe
Это означает, что у вас есть служба, работающая с проблемной учетной записью со старым паролем
.Я нашел этот старый вопрос, исследуя другую проблему, но для всех с аналогичной проблемой:
Код ошибки 0x18 означает, что учетная запись уже была отключена или заблокирована, когда клиент пытался аутентифицироваться.
Вам необходимо найти тот же идентификатор события с кодом ошибки 0x24 , который будет определить неудачные попытки входа в систему, которые привели к блокировке учетной записи. (Предполагается, что это происходит из-за неправильного кэшированного пароля.)
Затем вы можете посмотреть на адрес клиента для этих событий , чтобы увидеть, какая система передает неверные учетные данные. Оттуда вам нужно будет выяснить, является ли это служба со старым паролем, подключенным сетевым диском и т. Д.
Существует множество кодов сбоя, поэтому вам следует искать что-либо, кроме 0x18, чтобы определить, что вызвало блокировка аккаунта при отсутствии событий с кодами 0x24. Я считаю, что единственный тип сбоя, который приведет к блокировке, - это 0x24 (неверный пароль), но я могу ошибаться.
Kerberos 0x18 действительно является попыткой неверного пароля.
Kerberos 0x12 - учетная запись отключена, истек срок ее действия, заблокирован или ограничение времени входа в систему.
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771