Управление групповыми политиками в организации. Часть 3

Права доступа к файлам и папкам простым языком.

На просторах России много фирм и мелких предприятий не имеют в штате своего системного администратора на постоянной основе или приходящего время от времени. Фирма растёт и рано или поздно одной расшаренной папки в сети, где каждый может делать что захочет, становится мало. Требуется разграничение доступа для разных пользователей или групп пользователей на платформе MS Windows. Линуксоидов и опытных админов просьба не читать статью.

Самый лучший вариант — взять в штат опытного админа и задуматься о покупке сервера. Опытный админ на месте сам решит: поднимать ли MS Windows Server с Active Directory или использовать что-то из мира Linux.

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

Прежде чем начать хотелось бы разжевать пару моментов:

• Любая операционная система «узнаёт» и «различает» реальных людей через их учётные записи. Должно быть так: один человек = одна учётная запись.
• В статье описывается ситуация, что в фирме нет своего админа и не куплен, к примеру, MS Windows Server. Любая обычная MS Windows одновременно обслуживает по сети не более 10 для WinXP и 20 человек для Win7. Это сделано фирмой Microsoft специально, чтобы клиентские Windows не перебегали дорогу серверам Windows и вы не портили бизнес Microsoft. Помните число 10-20 и когда в вашей фирме будет более 10-20 человек, вам придётся задуматься о покупке MS Windows Server или попросить кого-либо поднять вам бесплатный Linux Samba сервер, у которого нет таких ограничений.
• Раз у вас нет грамотного админа, то ваш обычный комп с клиентской MS Windows будет изображать из себя файловый сервер. Вы вынуждены будете продублировать на нём учётные записи пользователей с других компьютеров, чтобы получать доступ к расшаренным файлам. Другими словами, если есть в фирме ПК1 бухгалтера Оли с учётной записью olya, то и на этом «сервере» (именую его в дальнейшем как WinServer) нужно создать учётную запись olya с таким же паролем, как и на ПК1.
• Люди приходят и уходят. Текучесть кадров есть везде и если вы, тот бедный человек, который не админ и назначен (вынужден) поддерживать ИТ вопросы фирмы, то вот вам совет. Делайте учётные записи, не привязанные к личности. Создавайте для менеджеров — manager1, manager2. Для бухгалтеров — buh1, buh2. Или что-то подобное. Ушёл человек? Другой не обидится, если будет использовать manager1. Согласитесь это лучше, чем Семёну использовать учётную запись olya, так как влом или некому переделывать и уже всё работает 100 лет.
• Забудьте такие слова как: «сделать пароль на папку». Те времена, когда на ресурсы накладывался пароль давным давно прошли. Поменялась философия работы с различными ресурсами. Сейчас пользователь входит в свою систему с помощью учётной записи (идентификация), подтверждая себя своим паролем (аутентификация) и ему предоставляется доступ ко всем разрешённым ресурсам. Один раз вошёл в систему и получил доступ ко всему — вот что нужно помнить.
• Желательно выполнять нижеперечисленные действия от встроенной учётной записи Администратор или от первой учётной записи в системе, которая по умолчанию входит в группу Администраторы.

Приоритеты объектов групповых политик и их наследование

Как известно, для управления настройками клиентских компьютеров и пользовательских учетных записей в организациях применяются объекты групповых политик. Объекты GPO могут быть привязаны к сайту организации, к домену или к подразделениям. Если объекты групповых политик были привязаны к сайту или домену, а также к подразделению, то для компьютеров и пользователей, которые размещены в данном подразделении, будут применяться объекты GPO, их подразделения, а также домена или сайта организации. Для того чтобы не было конфликтов параметров групповых политик, существуют приоритеты объектов GPO. Как было указано во второй части статьи, в консоли управления групповой политики, приоритеты объектов GPO отображаются в виде номера, причем, чем меньше значение объекта групповой политики, тем выше его приоритет. Объекты с самым высоким приоритетом имеют преимущества над остальными объектами. Параметры групповых политик унаследованы от верхнего уровня контейнеров до более низкого и, обычно, они применяются при включении компьютера и входа пользователем в систему в следующем порядке:

1. Локальные объекты групповой политики. Эти политики применяются самыми первыми. Они расположены на локальном компьютере;
2. Объекты групповой политики, назначенные на уровне сайта. После локальных объектов групповых политик применяются объекты групповой политики, которые расположены на сайте Active Directory.
3. Объекты групповой политики, назначенные на уровне домена. Далее обрабатываются объекты групповой политики, которые расположены на уровне домена Active Directory.
4. Объекты групповой политики, назначенные на уровне подразделения. Последними выполняются объекты GPO, которые расположены в подразделениях. Если были указаны параметры политик в объектах с более низкими приоритетами, которые отличаются от параметров в подразделениях, то в последнюю очередь применяются именно те политики, которые расположены на этом уровне. Если существуют дочерние подразделения, то приоритет таких подразделений будет превалировать над объектами GPO предшествующего подразделения.

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

Предположим, что в вашей организации к домену привязаны два объекта групповой политики и к подразделению «Группы» привязано три объекта. Изменить порядок приоритетов объектов GPO вы можете следующим образом:

1. Откройте консоль «Управление групповой политикой»;
2. В дереве консоли разверните узел «Управление групповой политикой», затем разверните узел леса, узел «Домены» и выберите свой домен, для которого будете изменять порядок приоритетов;
3. На вкладке «Связанные объекты групповой политики» выделите объект, приоритет которого планируете изменить и нажмите на кнопку «Переместить связь вверх» для перемещения объекта на один уровень вверх или на кнопку «Переместить связь на первое место», соответственно для того, чтобы данному объекту GPO назначить наивысший приоритет;

Рис. 1. Изменение приоритета объекта групповой политики

Рис. 2. Наследование групповой политики для контейнера «Группы»

При помощи консоли управления групповыми политиками вы можете запретить все наследования параметров политики для указанного домена или подразделения. Реализовать такой запрет можно при помощи команды «Блокировать наследования», которая блокирует все объекты групповой политики (GPO), связанные с сайтами, доменами или подразделениями родительского уровня от автоматического наследования на дочернем уровне. При блокировании наследования, скажем, подразделения, в этом подразделении применение политик будет начинаться непосредственно с данного подразделения. Но нужно учесть, что связи GPO, установленные принудительно невозможно заблокировать из родительского контейнера. Об использовании принудительных связей объектов групповых политик вы можете ознакомиться во второй части статьи «Управление групповыми политиками в организации». Узел с блокированным наследованием отображается в дереве консоли со значком синего круга с белым восклицательным знаком, как показано ниже:

Рис. 3. Подразделение с блокированным наследованием

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

Представим, наша задача – предоставить группе HelpDesk право на сброс пароля и разблокировку аккаунтов пользователей в домене. Итак, создадим новую группу в AD с помощью PowerShell:

New-ADGroup «HelpDesk» -path ‘OU=Groups,OU=Moscow,DC=corp,dc=winitpro,DC=ru’ -GroupScope Global

Добавьте в группу нужных пользователей:

Add-AdGroupMember -Identity HelpDesk -Members ivanovaa, semenovvb

Запустите консоль Active Directory Users and Computers (ADUC), щелкните ПКМ по OU с пользователями (в нашем примере это ‘OU=Users,OU=Moscow,DC=corp,dc=winitpro,DC=ru’) и выберите пункт меню Delegate Control.

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

Выберите из списка один из преднастроенных наборов привилегий (Delegate the following common tasks):

• Create, delete, and manage user accounts;
• Reset user passwords and force password change at next logon;
• Read all user information;
• Create, delete and manage groups;
• Modify the membership of a group;
• Manage Group Policy links;
• Generate Resultant Set of Policy (Planning);
• Generate Resultant Set of Policy (Logging);
• Create, delete, and manage inetOrgPerson accounts;
• Reset inetOrgPerson passwords and force password change at next logon;
• Read all inetOrgPerson information.

Либо создайте собственное задание делегирования (Create a custom task to delegate). Я выберу второй вариант.

Выберите тип объектов AD, на которые нужно предоставить права. Т.к. нам нужно предоставить права на учетные записи пользователей, выберите пункт User Object. Если вы хотите предоставить право на создание и удаление пользователей в этом OU, выберите опции Create/Delete selected objects in this folder. В нашем примере мы не предоставляем таких полномочий.

В списке разрешений нужно выбрать те привилегий, которые вы хотите делегировать. В нашем примере мы выберем право на разблокировку (Read lockoutTime и Write lockoutTime) и сброс пароля (Reset password).

Для поиска источника блокировки аккаунтов в домене службой поддержки пользователей нужно предоставить право поиска по журналам на контроллерах домена.

Нажмите Next и на последнем экране подтвердите назначение выбранных полномочий.

Теперь под учетной записью пользователя из группы HelpDesk попробуйте из PowerShell сбросить пароль пользователя из OU Users, например из PowerShell:

Set-ADAccountPassword petricdb -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “PPPPa$w0rd1” -Force -Verbose) –PassThru

Пароль должен сброситься успешно (если он соответствует доменной политике паролей).

Теперь попробуйте создать пользователя в данной OU с помомью командлета New-ADUser:

New-ADUser -Name kalininda -Path ‘OU=Users,OU=Moscow,OU=winitpro,OU=DC=ru’ -Enabled $true

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

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

Ограничения пользователей компьютера с помощью локальной групповой политики

Друзья, в одной из недавних статей сайта мы рассмотрели 5 способов ограничения возможностей пользователей компьютеров, реализуемых за счёт превалирования учётных записей администраторов над стандартными и использования функционала типа «Родительский контроль». В этой статье продолжим тему осуществления контроля пользователей, которым мы вынуждены иногда доверять свои компьютеры, однако не можем быть уверенными в их действиях в силу неосознанности или неопытности. Рассмотрим, какие ещё действия детей и неопытных взрослых можно ограничить в среде Windows. И для этих целей будем использовать штатный инструмент локальной групповой политики, доступный в редакциях Windows, начиная с Pro.

Групповая политика – это инструмент, с помощью которого можно гибко настроить работу Windows. Управление этим функционалом осуществляется посредством редактора gpedit.msc. Для быстрого запуска его название можно ввести в поле внутрисистемного поиска или команды «Выполнить». Редактор содержит две основных ветки параметров:

• «Конфигурация компьютера», где содержатся параметры для всего компьютера, то есть для всех его пользователей;

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

Доверие

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

Trusts — это соединение одного домена с другим. Не физическое сетевое соединение, а своего рода соединение для аутентификации/авторизации. Вы можете получить доступ к компьютерам в сети, которые находятся в других доменах, но вы не можете войти на эти компьютеры под своим пользователем этого домена. Это то, что доверие позволяет вам делать.

Направление доверия

Доверие – это направленное отношение, при котором одна сторона является доверяющей, а другая – доверенной. Когда эта связь установлена, пользователи доверенного домена могут получить доступ к ресурсам доверяющего домена.

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

Доверие от домена А к домену Б

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

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

Вы можете увидеть доверительные отношения вашего домена с помощью команды nltest /domain_trusts .

Трасты домена poke.mon

Здесь мы видим, что наш текущий домен poke.mon и есть пара трастов. Исходящее доверие с contoso.local указывает, что его пользователи могут получить доступ к нашему домену poke.mon . Более того, есть второй двунаправленный траст it.poke.mon , который является поддоменом poke.mon и находится в том же лесу.

Доверительные отношения contoso.local

Следовательно, если мы проверим доверие к contoso.local , мы увидим входящее соединение от poke.mon , что согласуется с предыдущей информацией. Таким образом, пользователи contoso.local могут получить доступ к файлам poke.mon .

Транзитивное доверие

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

Три домена, связанные доверием

Например, если доверие между доменом A и B является транзитивным, то пользователи домена C могут получить доступ к домену A через оба доверия. Если доверие между доменами A и B было нетранзитивным, то пользователи домена С не могли получить доступ к домену A, но это могли бы сделать пользователи домена B.

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

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

contoso.local доверяет лесам

Таким образом, чтобы получить доступ к компьютерам hr.contoso.local , пользователь webs.it.contoso.local должен пройти через 3 траста.

Типы доверия

В Active Directory существует несколько типов доверия для разных целей:

• Родительский-дочерний — доверительные отношения по умолчанию, созданные между родительским доменом и его дочерним;
• Лес — доверие для обмена ресурсами между лесами. Таким образом, любой домен леса может получить доступ к любому домену другого леса (если это позволяют направление и транзитивность доверия). Если доверие леса настроено неправильно, оно может позволить получить контроль над другим лесом;
• Внешний — доверие для подключения к определенному домену, который находится в недоверенном лесу;
• Область — специальное доверие для соединения Active Directory и домена, отличного от Windows;
• Ярлык — когда два домена в лесу часто взаимодействуют, но не связаны напрямую, вы можете избежать перехода через множество доверительных отношений, создав прямое сокращенное доверие.

Доверительный ключ

Технически, когда вы используете доверие, существует связь между контроллером домена вашего домена и контроллером домена целевого домена (или промежуточного домена). Способ установления связи зависит от используемого протокола (это может быть NTLM, Kerberos и т.д.), но в любом случае контроллеры домена должны совместно использовать ключ для обеспечения безопасности связи. Этот ключ известен как ключ доверия и создается при установлении доверия.

При создании доверия в базе данных домена создается доверительная учетная запись с именем, заканчивающимся на $ . Затем создается доверенный ключ, как пароль доверенного пользователя (в виде хеша NT и ключей Kerberos).

Ограничения пользователей компьютера с помощью локальной групповой политики

Друзья, в одной из недавних статей сайта мы рассмотрели 5 способов ограничения возможностей пользователей компьютеров, реализуемых за счёт превалирования учётных записей администраторов над стандартными и использования функционала типа «Родительский контроль». В этой статье продолжим тему осуществления контроля пользователей, которым мы вынуждены иногда доверять свои компьютеры, однако не можем быть уверенными в их действиях в силу неосознанности или неопытности. Рассмотрим, какие ещё действия детей и неопытных взрослых можно ограничить в среде Windows. И для этих целей будем использовать штатный инструмент локальной групповой политики, доступный в редакциях Windows, начиная с Pro.

Групповая политика – это инструмент, с помощью которого можно гибко настроить работу Windows. Управление этим функционалом осуществляется посредством редактора gpedit.msc. Для быстрого запуска его название можно ввести в поле внутрисистемного поиска или команды «Выполнить». Редактор содержит две основных ветки параметров:

• «Конфигурация компьютера», где содержатся параметры для всего компьютера, то есть для всех его пользователей;

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

Запустите задачу от имени администратора.

Один из способов справиться с Используемая учетная запись пользователя не имеет разрешения отключить эту задачу : запустить планировщик задач от имени администратора.

Шаги:

1. Нажмите на кнопку Пуск .
2. Введите планировщик задач, затем щелкните правой кнопкой мыши Планировщик задач и выберите Запуск от имени администратора.

Это добавляет больше прав к вашей уже привилегированной учетной записи администратора и может помочь вам исправить эту ошибку.