Клиент управления правами windows что это

Как предоставить обычным пользователям права на запуск/остановку служб Windows?

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

Предположим, нам нужно предоставить доменной учетной записи contoso\tuser права на перезапуск службы печати (Print Spooler) с системным именем Spooler. При попытке перезапустить службу под пользователей появляется ошибка: System error 5 has occurred. Access is denied.

Простого и удобного встроенного инструмента для управления разрешениями на службы в Windows нет. Мы рассмотрим несколько способ предоставления пользователю прав на службу:

Какой из них проще и удобнее – решать Вам.

Управление правами на службы с помощью встроенной утилиты SC.exe (Service controller)

Стандартный, встроенный в Windows способ управления правами на службы системы предусматривает использование консольной утилиты sc.exe (Service Controller).

Главная, проблема – зубодробительный синтаксис формата предоставления прав на сервис (используется формат SDDL — Security Description Definition Language).

Получить текущие разрешения на службу в виде SDDL строки можно так:

sc.exe sdshow Spooler

Что значат все эти символы?

Первая буква после скобок означает: разрешить (A, Allow) или запретить (D, Deny).

Следующая пачка символов – назначаемые права.

Последние 2 буквы — объекты (группа пользователей или SID), котором нужно назначить права. Есть список предустановленных групп.

AO Account operators
RU Alias to allow previous Windows 2000
AN Anonymous logon
AU Authenticated users
BA Built-in administrators
BG Built-in guests
BO Backup operators
BU Built-in users
CA Certificate server administrators
CG Creator group
CO Creator owner
DA Domain administrators
DC Domain computers
DD Domain controllers
DG Domain guests
DU Domain users
EA Enterprise administrators
ED Enterprise domain controllers
WD Everyone
PA Group Policy administrators
IU Interactively logged-on user
LA Local administrator
LG Local guest
LS Local service account
SY Local system
NU Network logon user
NO Network configuration operators
NS Network service account
PO Printer operators
PS Personal self
PU Power users
RS RAS servers group
RD Terminal server users
RE Replicator
RC Restricted code
SA Schema administrators
SO Server operators
SU Service logon user

Можно вместо предустановленной группы явно указать пользователя или группу по SID. Получить SID пользователя для текущего пользователя можно с помощью команды:

или для любого пользователя домена с помощью PowerShell комаднлета Get-ADUser:

Get-ADUser -Identity ‘iipeshkov’ | select SID

SID доменной группы можно получить с помощью командлета Get-ADGroup:

Чтобы назначить SDDL строку с правами на определённую службу, используется команда sc sdset. К примеру, права пользователю на службу spooler могут быть предоставлены следующей командой:
sc sdset Spooler «D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;S-1-5-21-2133228432-2794320136-1823075350-1000)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)»

Предоставление прав на перезапуск службы с помощью SubInACL

Для управления правами служб Windows гораздо проще воспользоваться консольной утилитой SubInACL из комплекта Sysinternals от Марка Руссиновича (права на которую вместе с автором теперь принадлежат Microsoft). Синтаксис этой утилиты гораздо проще и удобнее для восприятия. Рассмотрим, как предоставить права перезапуск службы с помощью SubInACL:

  1. Скачайте subibacl,msi со страницы (https://www.microsoft.com/en-us/download/details.aspx?id=23510) и установите ее на целевой системе;
  2. В командной строке с правами администратора перейдите в каталог с утилитой: cd “C:\Program Files (x86)\Windows Resource Kits\Tools\ ”
  3. Выполните команду: subinacl.exe /service Spooler /grant=contoso\tuser=PTO

Если вы все сделали верно, служба должна перезапуститься.

subinacl.exe /service Spooler /revoke=contoso\tuser

Process Explorer: Установка разрешений на службу

Достаточно просто изменить разрешения на службу с помощью еще одной утилиты Sysinternals — Process Explorer. Запустите Process Explorer с правами администратора и найдите в списке процессов процесс нужной вам службы. В нашем примере это spoolsv.exe (диспетчер очереди печати — C:\Windows\System32\spoolsv.exe). Откройте свойства процесса и перейдите на вкладку Services.

Нажмите на кнопку Permissions и в открывшемся окне добавьте пользователя или группу, которой нужно предоставить права на сервис и выберите уровень полномочий (Full Control/Write/Read).

Назначаем разрешения на службу с помощью PowerShell

В галерее TechNet имеется отдельный неофициальный модуль PowerShell для управления разрешениями на разные объекты Windows — PowerShellAccessControl Module (скачать его можно здесь). Этот модуль позволяет управлять правами на службы. Импортируйте модуль в свою PS сессию:

Получить эффективные разрешения на конкретную службу из PowerShell можно так:

Get-Service spooler | Get-EffectiveAccess -Principal corp\tuser

Чтобы предоставить обычному пользователю права на запуск и остановку службы, выполните:

Get-Service spooler | Add-AccessControlEntry -ServiceAccessRights Start,Stop -Principal corp\tuser

Используем шаблоны безопасности (Security Templates) для управления разрешениями служб

Более наглядный (но и требующий большего количества действий) графический способ управления правами на службы – с помощью шаблонов безопасности. Для реализации, откройте консоль mmc.exe и добавьте оснастку Security Templates.

Создадим новый шаблон (New Template).

Задайте имя нового шаблона и перейдите в раздел System Services. В списке служб выберите свою службу Print Spooler и откройте ее свойства.

Установите тип запуска (Automatic) и нажмите кнопку Edit Security.

С помощью кнопки Add добавьте учетную запись пользователя или группы, которым нужно предоставить права. В нашем случае, нам достаточно права Start, Stop and pause.

Сохраните шаблон (Save).

Если открыть этот файл, можно увидеть, что данные о правах доступа сохраняются в уже упомянутом ранее SDDL формате. Полученная таким образом строка может быть использована в качестве аргументы команды sc.exe.

Осталось с помощью оснастки Security Configuration and Analysis создать новую базу данных (Open Database) и импортировать новый шаблон безопасности из файла Spooler User Rights.inf.

Примените шаблон, вызвав из контекстного меню команду Configure Computer Now.

Теперь можно под пользователем проверить, что у него появились права на управление службой Print Spooler.

Управление правами служб через групповые политики

Если нужно раздать пользователям права запуска/остановки сервиса сразу на множестве северов или компьютерах домена, проще всего воспользоваться возможностями групповых политик (GPO).

  1. Создайте новую или отредактируйте существующую GPO, назначьте ее на нужный контейнер с компьютерами в Active Directory. Перейдите в раздел политик Computer configuration -> Windows Settings -> Security Settings -> System Services;
  2. Найдите службу Spooler и аналогично методике с шаблонами безопасности, рассмотренной ранее, предоставьте права пользователю. Сохраните изменения;

Настройки безопасности для все служб, для которых вы изменили разрешения по-умолчанию хранятся в собственной ветке реестра HKLM\System\CurrentControlSet\Services\ \Security в параметре Security типа REG_BINARY.

Это означает, что одним из способов установки аналогичных разрешений на других компьютерах может быть экспорт/импорт данного параметра реестра (в том числе через GPO).

Итак, мы разобрали несколько способов управления правами на службы Windows, позволяющих предоставить произвольному пользователю любые права на системные службы. Если пользователю требуется удаленный доступ к службе, без предоставления ему прав локального входа в систему, нужно разрешить пользователю удаленно опрашивать Service Control Manager.

Обзор службы управления правами Active Directory

Посетителей: 3730 | Просмотров: 5175 (сегодня 0) Шрифт:

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

Защита информации

Впервые служба управления правами появилась в качестве отдельного сервера под названием Rights Management Server (версия 1.0). На дистрибутивном диске поставлялся сам сервер и клиент для Windows 2000 и Windows XP.

С тех пор служба развивалась достаточно стремительно. Появилась поддержка мобильных пользователей, федеративных отношений, а теперь возможно аутентифицировать пользователя по паспорту Live ID, а также с использованием смарт-карт.

С выходом Microsoft Windows 2008, служба управления правами стала ролью серверной операционной системы (версия 2.0), изменилось и название – служба управления правами Active Directory (Active Directory Rights Management Services – сокращенно AD RMS). Начиная с Windows Vista, клиент службы управления правами поставляется также вместе с операционной системой. Также клиент AD RMS поставляется с Windows Mobile 6.0 и выше.

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

Служба управления правами является достаточно гибкой технологией – с помощью пакета разработки SDK можно встроить поддержку клиента AD RMS в бизнес-приложение организации и реализовать политики использования, которые необходимы. Служба управления правами расширяет существующую стратегию безопасности организации с помощью применения постоянных политик использования.

Политики использования указывают, какие сущности ( пользователи, или группы пользователей, компьютеры или приложения) являются доверенными. На любую сущность могут быть наложены права использования.

Состав службы управления правами

Здесь все достаточно просто. Есть два ключевых компонента:

  1. Сервер кластера службы управления правами, который предоставляет возможность выдачи, хранения и проверки всех необходимых для работы сертификатов.
  2. Клиент службы управления правами который, предоставляет возможность связи с кластером службы управления правами, со стороны клиентской операционной системы.

Служба управления правами использует формат сертификатов XrML (eXtensible rights Markup Language), отличный от распространенного стандарта X509v3. Стандарт XrML является расширением языка XML. Дополнительные сведения можно найти на сайте http://www.xrml.org/. Используется несколько видов сертификатов.

Таблица 1. Типы сертификатов AD RMS

Сертификат

Префикс

учетной записи службы управления правами

лицензии на использование

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

Понятие сертификата в службе управления правами точно такое же, как и в службе сертификации. Есть пара ключей – открытый и закрытый, которые находятся в цифровом сертификате. Сертификат находится в хранилище, доступ к которому защищается клиентом с помощью шифрования AES.

Можно посмотреть, как выглядят цифровые сертификаты, они находятся для Windows XP — %USERPROFILE%\Local Settings\Application Data\Microsoft\DRM, для Windows Vista и выше — %USERPROFILE%\AppData\Local\Microsoft\DRM.

Каждый пользователь должен иметь заполненное поле электронной почты в домене Active Directory.

Рисунок 1. Рабочий процесс использования AD RMS.

Рассмотрим на примере, как работает AD RMS:

  1. Автор создает документ и получает сертификат учетной записи пользователя, а также сертификат лицензиара клиента (выдается на компьютер) в первый раз, когда пытается защитить документ с помощью службы управления правами с помощью приложения.
  2. С использованием приложения (например, Microsoft Word), поддерживающего клиента AD RMS, автор создает документ, и указывает, какие права или состояния будут использоваться для этого файла.
  3. Приложение шифрует файл симметричным ключом, которым шифруется публичный ключ автора документа. Ключ вставляется в публикуемую лицензию и связывается с файлом. Только автор может использовать эту лицензию для расшифровки документа.
  4. Автор выкладывает файл, например, на внутренний ресурс компании.
  5. Пользователь, который желает получить доступ к содержимому документа, открывает его с использованием приложения поддерживающего AD RMS. Если пользователь не имеет сертификата своей учетной записи, расшифровка будет невозможна. В таком случае происходит процесс выдачи сертификата учетной записи пользователя, а также сертификата лицензиара клиента, так как описано в пункте 1.
  6. Приложение посылает запрос кластеру AD RMS. Запрос включает сертификат учетной записи получателя (содержащий публичный ключ получателя) и публичную лицензию использования (содержит симметричный ключ для расшифровки файла).
  7. Кластер службы управления правами проверяет запрос и создает лицензию на использование. Во время данного процесса сервер расшифровывает симметричный ключ с использованием закрытого ключа кластера, перешифровывает симметричный ключ с использованием публичного ключа получателя и добавляет шифрованный симметричный ключ в лицензию. Операция проходит успешно только в том случае, если получатель имеет права на данный документ.
  8. Когда подтверждается использование, кластер возвращает лицензию на использование на компьютер получателя.
  9. После получения лицензии на использование, приложение проверяет ее и сертификат учетной записи, делает проверку сертификатов. Если сертификаты действительны и не отозваны, а также не фиксируется состояния блокирующего доступ к документу (например, дата использования документа) приложение расшифровывает документ и возвращает его пользователю, в соответствии с правами, указанными в документе.

Приложения, поддерживающие AD RMS

Как можно заметить из описания работы службы управления правами, сама по себе она не используется. Использование может быть произведено с помощью приложения, которое поддерживает взаимодействие с клиентом службы управления правами.

На момент написания этой статьи существует целый ряд приложений, которые поддерживают службу управления правами [1]:

  • Microsoft Office System 2003 — Word, Excel, PowerPoint, Outlook
  • Microsoft Office 2007 — Word, Excel, PowerPoint, Outlook, InfoPath
  • Microsoft Office 2010 — Word, Excel, PowerPoint, Outlook, InfoPath
  • Microsoft Office SharePoint Server 2003
  • Microsoft Office SharePoint Server 2007
  • Microsoft SharePoint Server 2010
  • Microsoft Visio 2007 and Project 2007
  • Adobe Acrobat Reader (сторонняя разработка компаний FoxIt Software, Liquid Machines)
  • Exchange Server 2007
  • Exchange Server 2010
  • XPS (XML Paper Specification) v1.0
  • Internet Explorer (используется Add-on for IE)
  • IIS 6.0 (GigaTrust WebServer Add-on)

Пример использования AD RMS совместно c Microsoft Word 2010

Например, пользователь Егор Егоров должен переслать пользователю Сергею Сергееву секретный документ с использованием Microsoft Word 2010. Информация не должна быть никому раскрыта. Что делать Егору Егорову? Но тут он узнает, что в организации есть такая возможность! Эта возможность предоставлена службой управления правами! Итак, начнем.

Пользователь Егор Егоров открывает Microsoft Word 2010 и набирает необходимый текст. Для того чтобы зашифровать документ, он переходит в ленте Microsoft Word на элемент «Файл» — «Сведения» — «Защитить документ» — «Ограничить разрешения пользователей» — «Ограниченный доступ».

Рисунок 2. Включение ограничения доступа

При первом обращению к кластеру службы управления правами на компьютер Егора Егорова, будут получены все необходимые для работы сертификаты. Но сначала нужно пройти аутентификацию. В поле «Учетная запись», нужно ввести адрес электронной почты пользователя Егора Егорова. Нужно заметить, что службе управления правами не требуется, хотя и желательно, присутствие в домене сервера Exchange, адрес электронной почты заполняется в учетной записи пользователя домена Active Directory. В качестве пароля нужно использовать пароль для входа в домен. Итак, пользователь Егор Егоров вводит свои учетные данные (egorov@prod.local и пароль) и получает возможность использования службы управления правами на доступ к данным.

Рисунок 3. Основное окно разрешения ограничений доступа

Для этого нужно поставить флажок «Ограничить разрешения на доступ к этому файлу документа», и выставить необходимые права пользователю Сергею Сергееву. Если нужно поставить дополнительные разрешения, либо поменять существующие, можно нажать последовательно кнопки «Изменить разрешения» — «Дополнительные параметры».

Рисунок 4. Дополнительное окно разрешения ограничений доступа

В окне «Разрешения» можно:

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

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

Теперь пользователь Его Егоров может быть уверенным, что никто кроме Сергея Сергеева не откроет документ с помощью приложения Microsoft Word 2010.

Вывод

Службу управления правами легко использовать и настраивать – она достаточно гибкая, и ее можно внедрять для защиты документов в организации.

Статья опубликована в N7-8 журнала «Системный администратор».

Читайте также:  Загрузка linux через uefi
Оцените статью