Я только что потратил большую часть этого утра на звонок в службу поддержки поставщика, где мы в конечном итоге решили нашу проблему, вручную добавив учетную запись службы, которую их приложение использовало, в следующий Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/User Rights Assignment политики, которые устанавливались объектом групповой политики домена:
После перезагрузки сервера и получения обновленного объекта групповой политики наша учетная запись службы больше не генерирует следующее событие 4625 - события аудита входа в систему типа 4 при попытке запустить приложение:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 7/22/2013 9:27:04 AM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: server.constco.com
Description:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: server$
Account Domain: constco
Logon ID: 0x3e7
Logon Type: 4
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: service-account
Account Domain: constco
Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Status: 0xc000015b
Sub Status: 0x0
Документация поставщика проинструктировала нас добавить учетную запись службы в операторы резервного копирования и локальные группы опытных пользователей, что мы и сделали. Чтение вкладки «Объяснение» для каждой из требуемых политик назначения прав пользователей указывает на то, что операторы резервного копирования имеют эти права по умолчанию (TechNet, похоже, подтверждает этот). Между прочим, нет никакого упоминания о том, что опытному пользователю назначаются те Права, которые я могу найти, поэтому я не совсем уверен, почему это было требованием.
Почему нам пришлось явно назначить этой учетной записи службы те Права (Back up files and directories, Log on as a batch job, Restore files and directories) когда они уже должны были быть у него в силу того, что он был членом локальной группы операторов резервного копирования?
Какая связь между политиками прав пользователей и встроенными локальными группами? Являются ли политики прав пользователей составными частями, составляющими «мета» -права каждой встроенной локальной группы? Если да, то где я могу узнать, какие права принадлежат каким локальным группам?
Как уже говорилось, мы решили эту проблему, добавив нашу учетную запись службы к объекту групповой политики, который вручную назначает ряду учетных записей служб эти конкретные Права. У меня возникло ощущение от инженера поставщика, что этот объект групповой политики мешает сопоставлению этих составляющих прав локальным группам. Правильно ли это предположение? Является ли назначение таким образом основных прав пользователя плохой идеей (TM)?
Члены локальных встроенных групп (а также групп домена) имеют все права, назначенные группе. Права по умолчанию на сервере для локальных встроенных групп устанавливаются в настройках локальной безопасности. Чтобы получить доступ к локальным параметрам безопасности, нажмите Пуск, введите secpol.msc и нажмите Enter. В редакторе локальной политики безопасности разверните Локальные политики и щелкните Назначение прав пользователя. Там вы увидите, какие группы / пользователи и какие права предоставлены.
Параметры назначения прав локального пользователя могут быть отменены групповой политикой домена. Если вы создаете групповую политику домена, которая предоставляет определенным группам / пользователям определенное право, например «Вход в систему в качестве пакетного задания», это переопределит локальную политику, для которой пользователи имеют это право.
Из того, что вы написали, я предполагаю, что произошло следующее: у вас был объект групповой политики в вашем домене, который предоставлял определенным пользователям упомянутые вами права. Эта политика не предоставляла эти права группе операторов резервного копирования локальной машины. Эта политика заменила политику по умолчанию на сервере. Таким образом, добавление пользователя в группу «Операторы резервного копирования» не давало им этих прав, поскольку из-за объекта групповой политики домена операторы резервного копирования их не имеют.
Что касается того, является ли решение поставщика хорошей идеей: я обнаружил, что обычно легче управлять правами, используя хорошо организованные группы, чем предоставлять их отдельным учетным записям. Таким образом, когда вы добавляете нового пользователя, вы добавляете пользователя в логические группы, к которым он принадлежит, и он сразу же получает все необходимые права, вместо того, чтобы назначать ему права по одному. Именно для этого и предназначались встроенные группы.
Вместо того, чтобы предоставлять эти три права отдельному пользователю, вы могли бы предоставить группе «Операторы резервного копирования» эти три права в GPO. Затем добавление пользователя в эту группу даст желаемый эффект.
Мне любопытно, почему у вас вообще должна быть политика домена, управляющая этими правами. Если бы целью было предоставить определенным пользователям доступ для выполнения операций резервного копирования, возможно, было бы лучше использовать встроенную в домен группу операторов резервного копирования.