Как настроить права пользователей в домене

Обновлено: 17.05.2024

1. Создал Подразделение;
2. Прикрепил свежую GPO;
3. Отредактировал отображение имени последнего входящего пользователя.

Политики на клиентской машине и пользователе применяются.

Где и как решить следующие задачи:
1. Где задается параметр Запрос Административного доступа (логин пасс) на повышение прав? (Например: Изменение параметров сети, установка программ).
2. Все пользователи по умолчанию просто пользователи, как назначить одного из пользователей локальным Администратором подразделения входящих всех в него ПК?
3. Как заблокировать учетную запись локального Админа на всех машинах подразделения?

Назначение прав на сетевую папку в домене (Share)
Домен, подразделение с компьютерами и пользователями. Несколько вопросов по этой теме в.

Создание пользователя и назначение прав на папку
Всем доброго врмени суток. Не сочтите за труд посмотреть задания на создание пакетных файлов(не.

Ограничение прав пользователей в домене
Всем привет! Есть машина с win7, есть домен, машина введена в домен, на домене есть какие-то.

Назначение прав локальному пользователю
У меня есть точка доступа в интернет, под админской учетной записью выход в Интернет осуществляется.

Решение

1. Где задается параметр Запрос Административного доступа (логин пасс) на повышение прав? (Например: Изменение параметров сети, установка программ).

если пользователь не является администратором, то этот запрос будет появляться при любых действиях, требующих повышенных прав. Или я неправильно вас понял? Поясните, пожалуйста.

2. Все пользователи по умолчанию просто пользователи, как назначить одного из пользователей локальным Администратором подразделения входящих всех в него ПК?

В GPO:
1. Создать политику, которая будет распространяться на компьютеры подразделения.
2. В политике настроить добавление нужного пользователя в группу локальных администраторов:
Computer Configuration - Preferences - Control Panel Settings - Local Users and Groups - создаете новый объект Local Group

Action = Update
Group name = Administrators (built-in)
Members - Add - выбираете пользователя и Action = Add to this group

Computer Configuration - Preferences - Control Panel Settings - Local Users and Groups - создаете новый объект Local User

sys.tim, спасибо, все четко и ясно, п.2 и 3 понятен.
У меня походу не все политики применяются, ищу проблему.

В привязанной политике к подразделению включил два контроля: установка программ с повышением прав (запрос логин пасс) и любые действия обычного пользователя требующие повышение прав (логин пасс), все отрабатывает, но странно. Только при перезагрузке DC, gpupdate /force для контроля требует перезагрузку.

gpupdate обычно требует перезагрузку, если есть политики, применяемые при запуске ПК/логоне пользователя. Не факт, что просит перезагрузку именно из политик, которые вы сейчас настраиваете.

gpresult /v - говорит что нужные политики применились, но что конкретно - не видно.
Так же слепок вижу от старой политики. странно как-то, разбираюсь.

я обычно gpresult /H c:\temp\result.html использую - порой наглядно показывает, почему не применилась та или иная политика.

sys.tim, из остальных те 2 строчки ниже. они были прицеплены на уровне домена, в автозагрузке к ПК

sys.tim, вообщем не применяются политики на уровне подразделения, вернее к пользователю нормально, к компьютеру никак.

Запись в СИСВОЛ на клиенте есть, на добавление локального админа, но применения нет

Прикрепляю еще отчет result.zip

sys.tim, вообщем "прошедшие проверку" не получают групповые политики группы. что делать?

Не знаю что и делать, "прошедшие проверку" галка в свойствах безопасности политики стоит - применять.
Добавлял вручную "Пользователи домена", группу с "Пользователями" с применением политики - толку ноль.

В крупных организациях существует несколько команд ИТ-администраторов и специалистов службы поддержки и в этом случае необходимо делегирование полномочий. Например, специалисты службы поддержки или руководители групп могут сбрасывать пароли, системные администраторы могут изменять членство в группах, а управлять OU могут только ИТ-архитекторы.

Такое разделение обязанностей действительно полезно для оптимизации операций и безопасности.

Бесплатное тестирование
Лицензия Windows Server в подарок
ЦОД в Амстердаме

Чтобы выполнить делегирование управления, администраторы домена должны иметь разрешения или полные привилегии управления над OU. Это можно сделать несколькими способами: через Active Directory Users and Computers, командную строку, группы и пр.

Делегирование через Active Directory Users and Computers

Для того чтобы делегировать управление через Active Directory Users and Computers (dsa.msc). Выполните следующие действия:

Запустите Active Directory Users and Computers. Щелкните правой кнопкой мыши на OU, которому вы хотите делегировать управление, и выберите Delegate Control.

Появится мастер делегирования контроля, где вам нужно нажать "Next".

В появившемся окне нужно нажать "Add. " и выбрать пользователей или группы, которым вы хотите делегировать управление, и нажать "Next".

В окне "Tasks to Delegate" выберите задачи, которые вы хотите делегировать, вы также можете создать пользовательскую задачу с нуля.

Нажмите Next и Finish

Разрешения на делегирование можно просмотреть в свойствах OU на вкладке Security.

Делегирование через командную строку

Для делегирования прав доступа компания Microsoft разработала сервис dsacls.exe. Он хорошо подходит для назначения делегирования посредством скриптов. Он также хорошо подходит для отображения текущих прав доступа. Вы можете использовать параметр /a для отображения всех прав доступа у OU, например:

dsacls.exe "OU=Employees,DC=office,dc=local" /a

Здесь мы видим права доступа KJenkins, которые мы делегировали в нашем предыдущем примере.

Чтобы добавить новые делегированные привилегии для учетной записи, нам нужно назначить ей разрешения в соответствии с определенным синтаксисом. Синтаксис состоит из основных и дополнительных прав доступа, вот список основных:

- GR - чтение
- GE - исполнение
- GW - запись
- GA – полный доступ

Наиболее популярные расширенные права:

- SD - Удаление
- DT - Удаление объекта и всех дочерних объектов
- RC - Чтение информации о безопасности
- WD - Изменение доступа
- WO – Изменение владельца
- CC - Создание дочерних объектов
- DC - Удаление дочерних объектов
- RP - Чтение свойств
- WP - Запись свойств

Давайте делегируем нашему пользователю KJenkins права на удаление OU Employees:

dsacls.exe "OU=Employees,DC=office,DC=local" /G OFFICE\KJenkins:SD;

Делегирование через встроенные группы

По умолчанию существуют встроенные группы, такие как Account Operators и Server Operators, которые выполняют административные задачи в Active Directory.

Вы можете включить любого пользователя в эти группы и получить дополнительные полномочия в домене без необходимости предоставления полного доступа к управлению. Но имейте в виду, что встроенная группа Account Operators предоставляет больше разрешений, чем требуется на самом деле. Они могут создавать, изменять и удалять все объекты, кроме членов группы Domain Admins, во всех OU, кроме OU Domain Controllers.

Лучшие практики по делегированию прав в OU

- Постройте матрицу управления делегированием, чтобы документировать все права доступа к AD

- Всегда используйте группы при делегировании прав, не используйте отдельные учетные записи пользователей. Так вам будет проще и безопаснее предоставлять делегированный доступ

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

- Попробуйте протестировать настройки делегирования на предмет нежелательных эффектов.

Все знают, что очень важно защищать ресурсы в сети. Ресурсы, которые необходимо защищать, включают в себя папки и содержащиеся в них файлы, а также некоторые ключи реестра (Registry keys), которые размещаются на серверах и рабочих станциях по всей корпорации. Мы не должны забывать о тех объектах Active Directory, которые размещаются на контроллерах доменов (domain controller). Все эти ресурсы необходимо охранять таким образом, чтобы доступ к ним имели лишь те пользователи, которые должны его иметь. Для контроля прав к этим ресурсам у вас есть несколько вариантов. Некоторые их этих вариантов более привлекательны, чем другие, но необходимо рассмотреть все варианты.

Права на ресурсы 101

Прежде чем перейти к рассказу о правах на ресурсы, я должен объяснить, о каких ресурсах идет речь, а также как защищать ресурсы при помощи прав. Существует огромное число ресурсов в каждой сети, поэтому я не смогу перечислить все из них. Однако, я расскажу об основных ресурсах, которые вы захотите контролировать.

Перед тем, как я приведу список ресурсов, я хочу пояснить кое-что, что смущает даже опытных администраторов. Существует два типа прав, которые можно настроить на ресурсе. Есть NTFS права, а также права на общий доступ (share permission). Мы будем обсуждать права NTFS. Права на общий доступ в действительности не обеспечивают должной безопасности ресурса, т.к. эти ресурсы контролируют лишь доступ в общую папку (shared folder), вместо обеспечения последовательного доступа к дочерним папкам и файлам, которые в ней содержаться. Чтобы пояснить, где настраиваются каждые из этих прав, то права на общий доступ настраиваются с помощью закладки Share (Доступ), как показано на Рисунке 1.

Рисунок 1: Права на общий доступ контролируют вход к общей папки из сети

Права NTFS задаются в закладке Security (безопасность), как показано на рисунке 2.

Рисунок 2: Права NTFS размещаются и задаются в закладке Security (безопасность)

Примечание: Закладка Security (безопасность) не доступна для компьютеров, на которых не настроена тома NTFS. Эти тома, которые не являются NTFS, настроены в файловых системах FAT или FAT32.

Ресурсы, с которыми связаны права NTFS, включают в себя:

Папки
Файлы
Ключи реестра
Принтеры
Объекты Active Directory

Этот список ресурсов очень важен, т.к. только эти ресурсы могут иметь список контроля доступа Access Control List (ACL) в системе Windows. В этой статье мы сфокусируемся на том, как модифицировать права для папок, файлов и объектов Active Directory.

Ручная настройка прав для ресурсов для фалов и папок

Как я уже говорил ранее, вы можете перейти к закладке Security (безопасность) для файла или папки, чтобы получить доступ к списку прав. Есть несколько ключевых моментов, о которых необходимо помнить, при ручной настройке прав для этих ресурсов.

Во-первых, когда вы настраиваете права для файлов и папок, то лучше всего задавать права для групп, а не для отдельных пользователей. Во-вторых, вы должны задать уровень доступа для файла или для папки. Как показано на рисунке 3, существуют некоторые стандартные ресурсы, которые можно задать, не касаясь дополнительных прав для учетной записи.

Рисунок 3: Стандартные права для ресурса можно задать для каждой учетной записи

Рисунок 4 показывает, что вы также можете использовать дополнительные права (Advanced permission), и задать очень подробный уровень прав для каждого ресурса.

Рисунок 4: Дополнительные права позволяют настроить более четкий уровень доступа к ресурсу

Примечание:Нажав на кнопку Edit (редактировать), изображенную на рисунке 4, вы сможете увидеть полный список дополнительных прав. Это не лучший способ для управления ресурсами, т.к. приводит к дополнительным накладным расходам при настройке, управлении и отладке доступа к ресурсам.

Ручная настройка прав для ресурсов для объектов Active Directory

Процесс ручной настройки объектов Active Directory аналогичен, но существует мастер (Wizard), который может значительно облегчить настройку. Это очень удобный мастер, т.к. существует свыше 1000 персональных прав на некоторые объекты Active Directory, такие как организационные единицы, изображенные на рисунке 5.

Рисунок 5: Частичный список прав для организационной единицы

Для доступа к мастеру просто нажмите правой кнопкой мыши на узел, который хотите настроить. Появится меню Delegate Control. После его выбора появится диалоговое окно мастера Delegation of Control Wizard. Этот мастер позволяет вам задать “кто” (пользователь или группа) будет иметь “этот” уровень доступа (эти права) для объектов в Active Directory.

Примечание: Можно использовать закладку Security (безопасности) для объектов Active Directory, точно также, как для настройки прав для файлов или папок. Однако, это очень унылое занятие, которое может озадачить даже самых опытных администраторов.

Настройка прав для ресурсов с помощью политики групп (Group Policy)

Когда дело доходит до управления правами на ресурсы с помощью политик групп (Group Policy), то с ее помощью вы можете управлять лишь файлами и папками, но не объектами Active Directory. (Ключами реестра также можно управлять с помощью политик групп Group Policy). Настройки для управления этими правами расположены в разделе Computer Configuration (конфигурация компьютера) Group Policy, как показано на рисунке 7.

Рисунок 7: В узле File System (файловая система) можно настроить права на файлы и папки с помощью политики групп Group Policy

Чтобы воспользоваться этой возможностью вы должны создать объект политики группы Group Policy Object (GPO) и связать его с узлом, который содержит учетную запись компьютера, которую вы хотите настроить. После этого отредактируйте GPO и щелкните правой кнопкой на узле File System (файловая система). После выбора пункта меню Add File (добавить файл), вы сможете указать путь к файлу и/или папке, для которой вы хотите установить права. После того, как вы зададите путь, вы увидите закладку Security (безопасность) для этого ресурса, что видно на рисунке 8.

Рисунок 8: Права на безопасность можно задать для файлов и папок с помощью GPO

Хотя это и возможно, но не рекомендуется использовать политику групп Group Policy для редактирования или установки прав на эти ресурсы из-за производительности приложения. Доказано, что если слишком много прав задать с помощью политики групп Group Policy, то существенно замедляется начальный вход, а также работа системы из-за регулярного интервала обновления. Если используется эти настройки, то их следует использовать отдельно для нескольких ресурсов.

Настройка прав для ресурсов с помощью сценариев

После долгих исследований и анализа, я обнаружил, что использование сценариев для установки прав для ресурсов – это очень неэффективный способ установки прав, как для файлов и папок, так и для объектов Active Directory. Однако, я хочу упомянуть некоторые инструменты, которые могут помочь, если вы решите использовать сценарии.

Для установки прав для файлов и папок с помощью сценариев, вы можете использовать CACLS. CACLS позволяет вам задать и получать права для файлов и папок. Это бесплатный инструмент от компании Microsoft, который может использоваться отдельно или совместно с VB или другим языком для написания сценариев.

Для установки прав на объекты Active Directory вы можете использовать новые возможности PowerShell. PowerShell – это новинка, и доступна лишь для Windows XP и более поздних версий. PowerShell имеет мощь для управления правами Active Directory и многое другое.

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

Резюме

Контроль над сетевыми ресурсами и правами очень важен для защиты ресурсов вашей компании. Если вам нужно контролировать файлы HR, секреты компании, группы, организационные единицы или любые другие ресурсы, то вы должны установить права на каждый такой ресурс. В вашем распоряжении много возможностей, но этот выбор может сильно повлиять на эффективность и управляемость вашей сети. Ручные методы не очень просты и эффективны, но более точны и перегружают компьютеры в рабочее время. Политики группы (Group Policy) – это другой вариант, но убедитесь, но лучше ограничиться использованием его лишь для нескольких файлов и папок, так как применение этих прав может занять долгое время. Сценарии – это еще один вариант, но помните, что на написание и отладку сценария может уйти гораздо больше времени, чем на ручную установку прав.

Этот пост February 15, 2008 at 11:08 am опубликовал molse в категории администрирование Windows. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

One Comment

Спасибо, напомнили. А то уже и подзабыл, как эти права устанавливаются, а вот потребность появилась в связи с последними вирусами против WebMoney. Попробую немного ужесточить доступ.

Учетные записи ( accounts ) пользователей, компьютеров и групп — один из главных элементов управления доступом к сетевым ресурсам, а значит, и всей системы безопасности сети в целом.

В среде Windows 2003 Active Directory существует 3 главных типа пользовательских учетных записей:

Локальные учетные записи пользователей. Эти учетные записи существуют в локальной базе данных SAM ( Security Accounts Manager ) на каждой системе, работающей под управлением Windows 2003. Эти учетные записи создаются с использованием инструмента Local Users and Groups ( Локальные пользователи и группы ) консоли Computer Management ( Управление компьютером ). Заметим, что для входа в систему по локальной учетной записи, эта учетная запись обязательно должна присутствовать в базе данных SAM на системе, в которую вы пытаетесь войти. Это делает локальные учетные записи непрактичными для больших сетей, вследствие больших накладных расходов по их администрированию.
Учетные записи пользователей домена. Эти учетные записи хранятся в Active Directory и могут использоваться для входа в систему и доступа к ресурсам по всему лесу AD. Учетные записи этого типа создаются централизованно при помощи консоли " Active Directory Users and Computers " (" Active Directory – пользователи и компьютеры ").
Встроенные учетные записи. Эти учетные записи создаются самой системой и не могут быть удалены. По умолчанию любая система, будь то изолированная (отдельно стоящая) или входящая в домен, создает две учетные записи – Administrator ( Администратор ) и Guest ( Гость ). По умолчанию учетная запись Гость отключена.

Сосредоточим свое внимание на учетных записях пользователей домена. Эти учетные записи хранятся на контроллерах домена, хранящих копию базы данных Active Directory.

Существуют различные форматы, в которых могут быть представлены имена для входа пользователей в систему, потому что они могут отличаться для целей совместимости с клиентами, работающими под управлением более ранних версий Windows (такими как 95, 98, NT). Два основных вида имен входа — это с использованием суффикса User Principal Name ( основного имени пользователя ) и имя входа пользователя в системах пред-Windows 2000.

Основное имя пользователя ( UPN, User Principle Name ) имеет такой же формат, как и электронный адрес. Он включает в себя имя входа пользователя, затем значок " @ " и имя домена. По умолчанию доменное имя корневого домена выделено в выпадающем окне меню, независимо от того, в каком домене учетная запись была создана (выпадающий список будет также содержать имя домена, в котором вы создали эту учетную запись).

Также можно создавать дополнительные доменные суффиксы (та часть имени, которая стоит после знака @ ), которые будут появляться в выпадающем списке и могут быть использованы при образовании UPN, если вы их выберете (это делается при помощи консоли " Active Directory – домены и доверие " (" Active Directory Domain and Trusts ").

Существует только одно обязательное условие при этом — все UPN в лесу должны быть уникальными (т.е. не повторяться). Если учетная запись входа пользователя использует UPN для входа в систему Windows 2003, вам необходимо только указать UPN и пароль — более нет нужды помнить и указывать доменное имя. Другое преимущество данной системы именования состоит в том, что UPN часто соответствует электронному адресу пользователя, что опять уменьшает количество информации о пользователе, которую необходимо запоминать.

Локальные учетные записи

Каждый компьютер с операционными системами Windows NT/2000/XP/2003 (если это не сервер, являющийся контроллером домена) имеет локальную базу данных учетных записей, называемую базой данных SAM. Эти БД обсуждались при описании модели безопасности "Рабочая группа". Локальные пользователи и особенно группы используются при назначении прав доступа к ресурсам конкретного компьютера даже в доменной модели безопасности. Общие правила использования локальных и доменных групп для управления доступом будут описаны ниже.

Управление доменными учетными записями пользователей

Доменные учетные записи пользователей (а также компьютеров и групп) хранятся в специальных контейнерах AD. Это могут быть либо стандартные контейнеры Users для пользователей и Computers для компьютеров, либо созданное администратором Организационное подразделение (ОП). Исключение составляют учетные записи контроллеров домена, они всегда хранятся в ОП с названием Domain Controllers.

Рассмотрим на примерах процесс создания учетных записей пользователей в БД Active Directory и разберем основные свойства доменных учетных записей. Учетные записи для компьютеров создаются в процессе включения компьютера в домен.

Создание доменной учетной записи

Откроем административную консоль " Active Directory – пользователи и компьютеры ".
Щелкнем правой кнопкой мыши на контейнере, в котором будем создавать учетную запись, выберем в меню команду " Создать " и далее — " Пользователь ".
Заполним поля " Имя ", " Фамилия ", например, " Иван " и " Иванов " (в английской версии — First Name, Last Name ), поле " Полное имя " ( Full Name ) заполнится само.
Введем " Имя входа пользователя " ( User logon name ), например, User1. К этому имени автоматически приписывается часть вида " @ ", в нашем примере — " @world.ru " (полученное имя должно быть уникальным в масштабах леса).
В процессе формирования имени входа автоматически заполняется " Имя входа пользователя (пред-Windows 2000) " ( User logon name (pre- Windows 2000) ), создаваемое для совместимости с прежними версиями Windows (данное имя должно быть уникально в масштабе домена). В каждой организации должны быть разработаны схемы именования пользователей (по имени, фамилии, инициалам, должности, подразделению и т.д.) В нашем примере получится имя " WORLD\User1 ". Нажмем кнопку " Далее " (рис. 6.43):

Требовать смену пароля при следующем входе в систему (полезно в случае, когда администратор назначает пользователю начальный пароль, а затем пользователь сам выбирает пароль, известный только ему);
Запретить смену пароля пользователем (полезно и даже необходимо для учетных записей различных системных служб);
Срок действия пароля не ограничен (тоже используется для паролей учетных записей служб, чтобы политики домена не повлияли на функционирование этих служб, данный параметр имеет более высокий приоритет по сравнению с политиками безопасности);
Отключить учетную запись.

Нажмем кнопку " Далее " (рис. 6.44):

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

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

Данные политики устанавливаются исключительно для удобства выполнения упражнений, которые необходимо выполнять с правами простых пользователей на серверах-контроллерах домена. В реальной практике администрирования такие слабые параметры безопасности ни в коем случае устанавливать нельзя, требования к паролям и правам пользователей должны быть очень жесткими (политики безопасности обсуждаются далее в этом разделе).

Правила выбора символов для создания пароля:

И еще одно правило безопасности — регулярная смена пароля (частота смены зависит от требований безопасности в каждой конкретной компании или организации). В доменах Windows существует политика, определяющая срок действия паролей пользователей.

Обзор свойств учетных записей пользователей

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

Рассмотрим наиболее важные с точки зрения администрирования свойства.

Откроем консоль " Active Directory – пользователи и компьютеры " и посмотрим свойства только что созданного нами пользователя.

Закладка " Общие ". На данной закладке содержатся в основном справочные данные, которые могут быть очень полезны при поиске пользователей в лесу AD. Наиболее интересные из них:

" Имя "
" Фамилия "
" Выводимое имя "
" Описание "
" Номер телефона "
" Электронная почта "

Закладка " Адрес " — справочная информация для поиска в AD.

Закладка " Учетная запись " — очень важный набор параметров (параметры " Имя входа пользователя " и " Имя входа пользователя (пред-Windows 2000) " обсуждались выше при создании пользователя):

Закладки " Телефоны ", " Организация " — справочная информация о пользователе для поиска в AD.

Закладка " Профиль "

Профиль ( profile ) — это настройки рабочей среды пользователя. Профиль содержит: настройки рабочего стола (цвет, разрешение экрана, фоновый рисунок), настройки просмотра папок компьютера, настройки обозревателя Интернета и других программ (например, размещение папок для программ семейства Microsoft Office). Профиль автоматически создается для каждого пользователя при первом входе на компьютер. Различают следующие виды профилей:

локальные — хранятся в папке " Documents and Settings " на том разделе диска, где установлена операционная система;
перемещаемые (сетевые, или roaming ) — хранятся на сервере в папке общего доступа, загружаются в сеанс пользователя на любом компьютере, с которого пользователь вошел (зарегистрировался) в домен, давая возможность пользователю иметь одинаковую рабочую среду на любом компьютере (путь к папке с профилем указывается на данной закладке в виде адреса \\server\share\%username% , где server — имя сервера, share — имя папки общего доступа, %username% — имя папки с профилем; использование переменной среды системы Windows с названием %username% позволяет задавать имя папки с профилем, совпадающее с именем пользователя);
обязательные ( mandatory ) — настройки данного типа профиля пользователь может изменить только в текущем сеансе работы в Windows, при выходе из системы изменения не сохраняются.

Закладка " Член групп " — позволяет управлять списком групп, в которые входит данный пользователь.

Управление доступом пользователя в корпоративную систему через средства удаленного доступа системы Windows Server (например, через модем или VPN-соединение). В смешанном режиме домена Windows доступны только варианты " Разрешить доступ " и " Запретить доступ ", а также параметры обратного дозвона (" Ответный вызов сервера "). В режимах " Windows 2000 основной " и " Windows 2003 " доступом можно управлять с помощью политик сервера удаленного доступа (не надо путать с групповыми политиками). Подробнее данный вопрос обсуждается в разделе, посвященном средствам удаленного доступа.

Закладки " Профиль служб терминалов ", " Среда ", " Сеансы ", " Удаленное управление " — данные закладки управляют параметрами работы пользователя на сервере терминалов:

Локальные (или встроенные) группы безопасности создаются при установке операционной системы и служат для назначения пользователям прав доступа к различным ресурсам на отдельно взятом компьютере. Групп довольно много, но на практике используются всего две:

Пользователи (Users) — могут запускать приложения и работать с ними, но не имеют прав на изменение параметров системы.
Администраторы (Administrators) — имеют полные и ничем не ограниченные права доступа к компьютеру.

В группу Администраторы входит встроенная учетная запись администратора, учетная запись под которой производилась установка системы и (если компьютер входит в домен) группа Администраторы домена (Domain Admins). Все остальные локальные и доменные пользователи по умолчанию помещаются в группу Пользователи и не имеют административных полномочий на локальном компьютере.

Для того, чтобы добавить доменного пользователя в локальную группу безопасности на одном компьютере, можно особо не мудрить и воспользоваться оснасткой Локальные пользователи и группы (Local users and groups). Однако, если эту процедуру необходимо проделать с большим количеством компьютеров (например, добавить сотрудников техподдержки в группу локальных админов на всех компьютерах сети), то лучше воспользоваться групповыми политиками.

Групповые политики предоставляют два варианта добавления пользователей, и мы рассмотрим их оба. И первый способ, это:

Группы с ограниченным доступом, или Restricted Groups

Несмотря на свое название, эта политика не ограничивает доступ, а позволяет добавить доменных пользователей в локальные группы безопасности. Находится она в узле Конфигурация компьютера\Политики\Параметры безопасности (Computer configuration\Policies\Security Settings)

Добавить пользователей в локальные группы довольно просто, достаточно создать синоним локальной группы Администраторы и добавить туда нужную доменную группу (или отдельных пользователей). Тогда члены этой группы станут локальными администраторами и смогут входить на любую рабочую станцию с административными привилегиями.

Однако есть некоторые нюансы, а именно: если сначала добавить в Restricted Groups группу Администраторы, а затем в нее добавить доменную группу (в нашем случае HelpDesk), то локальными администраторами останутся только встроенный Администратор и добавленная нами группа HelpDesk, а все остальные, даже если они были добавлены вручную, будут из этой группы удалены. Более того, добавить обратно этих пользователей можно будет только одним способом — через Restricted Groups, при этом они станут станут локальными админами на всех компьютерах, на которые действует эта политика.

Поэтому, чтобы избежать подобных последствий, сначала добавляем в Restricted Groups доменную группу HelpDesk, а уже ее в группу Администраторы. В этом случае члены группы HelpDesk станут локальными администраторами вместе с уже заведенными пользователями и останется возможность добавлять пользователей в группу локальных администраторов вручную.

Этот способ работает на всех операционных системах, начиная с Windows 2000. Если же у вас в качестве клиентской операционной системы используется Windows 7, то можно воспользоваться вторым способом:

Предпочтения групповой политики или Group Policy Preferences

Системы на базе Windows 7 поддерживают расширения обычных групповых политик, названные Предпочтениями (Preferences). Предпочтения настраиваются только в объектах групповых политик, хранящихся в доменах Active Directory на базе серверов Windows Server 2008 и 2008 R2.

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

Для добавления пользователей в локальные группы с помощью предпочтений идем в раздел Конфигурация компьютера\Настройка\Параметры панели управления (Computer Configuration\Preferences\Control Panel Settings) и выбираем пункт Локальные пользователи и группы (Local User and Groups)

Щелкаем правой клавишей мыши на пустом поле, и в контекстном меню выбираем пункт Создать — Локальная группа

Открывается окно свойств локальной группы, в котором мы и будем настраивать членство в группе и другие опции. В качестве действия можно выбрать один из 4 вариантов:

Обновить (по умолчанию) — выбранные пользователи просто добавляются в локальную группу
Заменить — выбранные пользователи добавляются в группу, при этом все остальные члены группы удаляются
Создать — создается новая локальная группа, в которую добавляются выбранные пользователи
Удалить — удаляются все члены выбранной локальной группы

В поле имя группы выбираем Администраторы (встроенная учетная запись), это выберет группу локальных администраторов, даже если она была переименована. Затем жмем на кнопку Добавить и в качестве членов группы выбираем доменную группу HelpDesk. Теперь осталось нажать ОК, и наша группа техподдержки будет добавлена в группу локальных админов на всех рабочих станциях домена.

А если вы хотите полностью контролировать всех участников локальной группы Администраторы, то можно отметить пункты Удалить всех пользователей-членов этой группы (Delete all member users) и Удалить все группы-члены этой группы (Delete all member groups). Теперь, даже если вручную добавить туда нового пользователя или группу, при следующей перезагрузке список членов группы будет обновлен в соответствии со списком, указанным в групповой политике.

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

Читайте также: