Эта статья описывает (относительно трудоемкие) шаги, которые необходимо выполнить, чтобы предоставить пользователю Active Directory право «Вход в систему в качестве службы». Однако, если я устанавливаю службу и вручную указываю учетные данные для входа в мою учетную запись AD (свойства службы | Вход в систему), Windows сообщает мне, что «Учетной записи [myaccount] было предоставлено право входа в систему в качестве службы». Затем я могу запустить службу под своей учетной записью. Однако при последующей переустановке службы (или иногда при перезагрузке) служба снова не может запуститься из-за сбоя входа в систему ... пока я не войду и не введу вручную свои учетные данные снова, и учетная запись волшебным образом не будет предоставлена право «Вход в систему как услуга». После этого сервис снова может запуститься под моей учетной записью.
Что тут происходит? Почему у меня, по-видимому, есть разрешение предоставить себе это право на лету? Если я могу предоставить его на лету, почему он не остается предоставленным, и я должен продолжать предоставлять его повторно? Имейте в виду, что я не спрашиваю, как предоставить кому-либо это право через Active Directory - я говорю о том факте, что это право предоставляется Windows автоматически при вводе учетных данных в окне входа в систему.
Похоже, что существует групповая политика, определяющая учетные записи, которым разрешен вход в качестве службы. Поскольку вы являетесь администратором, у вас есть разрешение на предоставление этой привилегии, но при повторном применении групповой политики привилегия будет удалена. В следующий раз, когда служба остановится, она не сможет запуститься.
Вам следует либо изменить область действия / фильтрацию политики, чтобы этот компьютер был освобожден от нее, либо использовать политику для предоставления необходимых привилегий.
ИНФОРМАЦИЯ ИЗ КОММЕНТАРИЙ: Чтобы проверить, применяет ли групповая политика параметр, используйте мастер результирующего набора политик (rsop.msc)
Если вы хотите применить этот параметр ко многим компьютерам или не можете удалить существующую политику, которая определяет этот параметр, используйте групповую политику для его определения. Eсть статья в технике это объясняет, как это сделать.
Чтобы проверить текущие локальные параметры безопасности, используйте secpol.msc - разверните «Локальные политики», затем выберите «Назначение прав пользователей». Это покажет текущие применяемые настройки. Если у вас есть достаточный доступ и не действует групповая политика, это позволит вам редактировать текущую политику. Если кнопки добавления / удаления отключены, тогда политика в настоящее время определяет этот параметр.
Если нет действующей политики, то разрешение окнам предоставлять пользователю права - это совершенно нормально, и это просто удобная функция, предоставляемая окнами. Как обнаружил Джез, если действует политика, бороться с ней бессмысленно. Как правило, политика повторно применяется каждые несколько часов и будет отменять любые изменения, которые вам удалось внести. (Хотя сервис будет работать до остановки по какой-то другой причине). Джез упомянул, что он считает, что служба идентифицируется с помощью LUID, созданного во время установки. Я не знаю, так это или нет, но право пользователя «Вход в качестве службы» не ограничивается какой-либо конкретной службой. Так что не будет никакой разницы, в какой сервис вы хотите войти. Одна из опасностей, позволяющих Windows назначать вам права, заключается в том, что вы можете забыть удалить предыдущие учетные записи и в конечном итоге получить огромный список учетных записей, для которых вход в систему является служебной привилегией, и в этом нет необходимости.
Итак, чтобы ответить на комментарий Джеза немного более прямо, если есть действующая политика, нет смысла искать способы обойти отключенный пользовательский интерфейс secpol.msc. Пользовательский интерфейс отключен в качестве предупреждения для вас, что любые изменения, которые вам удастся внести, не будут сохранены. В этом случае изменение политики - это путь вперед, либо для предоставления привилегии, либо для прекращения настройки этого параметра, чтобы его можно было назначить локально.
РЕДАКТИРОВАТЬ: Вы, кажется, думаете, что предоставление пользователю домена этого права чем-то отличается от предоставления его локальному пользователю. Это не так. Если к рассматриваемому ПК / серверу не применяется какая-либо групповая политика, вы открываете secpol.msc, переходите к нужной привилегии, дважды щелкните, щелкните «Добавить» и затем выберите нужную учетную запись. Я только что попробовал это на ноутбуке, присоединенном к домену, и диалоговое окно добавления пользователя фактически по умолчанию относится к домену. Если бы я хотел выбрать местную группу, мне пришлось бы сменить местоположение.
Если вы дважды щелкните привилегию, я предполагаю, что вы видите список и кнопки добавления / удаления, но кнопки отключены, поэтому вы не можете редактировать список. Этого не может быть, потому что вы добавляете учетную запись домена, потому что вы еще не выбрали, добавлять ли локальную или доменную учетную запись.
Я столкнулся именно с этой проблемой на работе, служба, которую я устанавливал, работала только на одном ПК, поэтому изменение политики было невозможным. Мы переместили соответствующий компьютер в подразделение, к которому не применялась политика, после чего я мог предоставить привилегию без проблем.
Причина, по которой вы можете предоставить привилегию циклическим способом, заключается в том, что политика просто отключает пользовательский интерфейс, но фактически не меняет имеющиеся у вас разрешения. Однако он периодически применяется повторно, поэтому настройка перезаписывается.
В этой статье описывается ADAM (режим приложения Active Directory), который сильно отличается от стандартной стандартной установки Active Directory ... Просто стоит подумать.
Время для мнения - я также считаю, что когда вы устанавливаете (или переустанавливаете) службу, она генерирует для нее UID в реестре. Некоторые из его настроек, вероятно, связаны с этим, включая аутентификацию.
Давайте получим это прямо -
Это означает, что существует проблема с вашими сохраненными учетными данными, а НЕ с тем, что вы периодически теряете право входа в систему в качестве службы.
Во-первых, я бы порекомендовал создать новую учетную запись пользователя для запуска этой службы, а не использовать ваши учетные данные, установить пароль для учетной записи, который никогда не истечет, и предоставить учетной записи вход в систему как права службы. Лучшая практика - всегда использовать выделенную учетную запись для программного обеспечения, работающего как услуга, а не повторно использовать учетные записи пользователей.
Затем посмотрите, не возникнет ли проблема снова, и если да, попытайтесь выяснить, что именно было сделано, чтобы это не удалось, т.е. вам нужно повторно вводить учетные данные при каждом перезапуске сервера?
Кроме того, почему вы периодически переустанавливаете службу? Есть ли другие проблемы с этим программным обеспечением?
Это не кажется правильным вопросом. Есть ли вероятность, что ваш пароль меняется между перезапусками этой службы? Если это так, вам нужно будет изменить сброс в настройках сервиса. Лучше создать сервисный аккаунт, где пароль не меняется