2

По сути, у нас есть сервис, в котором мы используем локальную учетную запись для входа в систему. у него есть все необходимые разрешения, и все работает нормально, служба запускается и работает, и все хорошо. Затем однажды, после перезагрузки, служба не запускается. Журналы показывают неверный пароль. Наши специалисты решают проблему, просто повторно вводя пароль на вкладке "Вход в систему" на сайте services.msc. К сожалению, мы не смогли устранить причину. Я подозреваю, что пароль, который хранится для сервиса, как-то утерян. Кто-нибудь знает, где хеш пароля может храниться, чтобы мы могли проверить это? Единственные действия, которые могут быть связаны, это исправления с помощью исправлений безопасности Microsoft, но у нас есть несколько серверов, на которых работает одна и та же служба, и мы никогда не видели более одного за раз, и каждый раз, когда это происходит, обычно это разные.

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

ОБНОВЛЕНИЕ: Мы связали эту проблему с политикой входа в систему как сервис. Аккаунт как-то удален из этой настройки. Повторный ввод пароля в консоли служб повторно добавляет учетную запись к этой политике. Теперь нам нужны предложения о том, как устранить причину, по которой аккаунт был удален. Мы включили "изменение политики аудита" и настроили аудит как на успех, так и на неудачу.

2 ответа2

4

Для тех, кто все еще ищет ответ на этот вопрос. Проблема в том, что у вас есть политика, и эта учетная запись не настроена для запуска в качестве службы. При повторном вводе пароля он предоставляет учетной записи « Запуск от имени службы» права. В зависимости от версии ОС вы можете запустить gpresult /H filename.html /F и посмотреть на применяемые политики. Затем добавьте эту учетную запись в групповую политику, предоставив права учетной записи службы.

0

У меня нет окончательного решения для вас, но простой шаг устранения неполадок состоит в том, чтобы повторно ввести пароль для учетной записи службы, применить, затем остановить и перезапустить службу. Это должно начаться просто отлично. Если нет, то может возникнуть проблема с разрешениями при записи хэша в SAM. Вы можете использовать ProcessMonitor с http://sysinternals.com, чтобы помочь определить проблему с разрешениями.

Если служба перезапускается, и проблема возникает только после определенного периода времени или перезагрузки, то что-то меняет пароль. Для этого вам нужно будет включить аудит, чтобы увидеть, когда / если он изменится.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .