Сейчас на практике будем убеждаться, что AD не бесполезная штука для офиса (даже для не самого большого - на 30-50 компов). Для начала приведём нашу базу пользователей в надлежащее состояние - раскидаем всех по подразделениям и создадим группы. И потом посмотрим на сетевые папки и групповые политики с логон-скриптами.
Итак, группы и подразделения. Помните создавали подразделение СТАДО в прошлой статье? Сейчас в этом подразделении создадим вложенные - Бухгалтерия, Отдел продаж, Отдел ИТ. В нашем примере пользователей в АД мало, так что особого повышения удобства от того, что мы сунем единственную бухгалтершу Машу в отдельное подразделение Бухгалтерия, мы не ощутим, однако в реальных условиях, когда бухгалтерия состоит из целой толпы Маш, это сильно снизит наши энергозатраты на администрирование. Заходим в оснастку Active Directory - Пользователи и компьютеры, и в нашем подразделении СТАДО жмём Создать > Подразделение и вводим имя Бухгалтерия.
Тем же ловким приёмом создаём Отделы продаж и ИТ. Растаскиваем Машу в бухгалтерию, менеджеров в отдел продаж, компьютерщика в ИТ, директора оставим как есть. На выскакивающие предупреждения можно не обращать внимание - никакие групповые политики мы ещё не настраивали.
Это были подразделения, сейчас создадим группы. Создадим и потом поговорим о разнице. Там же создаём подразделение Отделы, и в нём жмём Создать > (угадайте что) Группу. Создаём те же группы - Бухгалтерия, Отдел продаж, Отдел ИТ.
Ну и в свойствах каждой группы на вкладке Члены группы добавляем, кого надо.
Теперь давайте разберёмся.
Подразделение - своего рода маленький домен. Вы можете делегировать права на его управление кому-либо из пользователей домена, можете накладывать групповые политики, которые будут иметь силу только в пределах подразделения... короче говоря, это область, содержащая объекты и накладывающая на них правила. А группа - это собственно и есть один из объектов, к которому эти правила применяются. Группами можно оперировать при создании правил доступа к ресурсам - например, если вы хотите запретить доступ в общую папку сразу нескольким пользователям то можно либо перечислить их по одному, либо указать группу, в которую они входят. Ещё различие: пользователь может находиться только в одном подразделении, однако его можно запихать в сколько угодно групп.
И ещё раз вернёмся к скрину, на котором показано окно создания новой группы. Там были указаны параметры - область действия группы и тип группы. Скажем пару слов о них.
Тип группы:
- Группа безопасности - это то, что мы создавали, с их помощью можно управлять доступом к объектам домена.
- Группа распространения используются только для почтовых рассылок программами типа MS Exchange
Область действия:
- Локальная группа содержит учётки из любого домена, но предоставляет правила доступа к ресурсам только того домена, в котором она определена.
- Глобальная группа наоборот содержит учётки из локального домена, но определяет доступ к ресурсам любого домена.
- Универсальная группа может содержать любые учётки и предоставлять доступ куда угодно. Не рекомендуется к использованию в силу своей избыточности.
Переходим обратно к практике. Создадим в корне C: папку SHARE и ней создадим ещё две папки: документы и vip документы. Заходим в свойства папки SHARE, на вкладке Доступ нажимаем на Общий доступ.
Теперь нам надо выбрать, кому давать доступ к этой папке. В папке SHARE у нас будут лежать все общие файлы - некоторые из них для всех, другие можно видеть только определённым сотрудникам. Так что дадим доступ к SHARE всем, а дальше будем разбираться конкретно с каждой вложенной папкой. В ответ на вопрос "кому давать доступ?" нужно как-нибудь указать объект, который бы содержал все учётки наших сотрудников. Как мы уже выяснили до этого, такой объект - группа. В AD есть предустановленные стандартные группы, одна из них нам подойдёт. Это группа "Пользователи домена", куда автоматически добавляются все пользователи текущего домена. Вбиваем группу Пользователи домена и даём ей разрешение совладелец.
Для справки:
- Читатель - может только читать файлы.
- Соавтор - может читать, создавать новые файлы, изменять и удалять созданные им файлы.
- Совладелец - может читать, создавать новые файлы, изменять и удалять любые файлы.
В данный момент в папку может зайти любой пользователь домена и все операции будут ему доступны. Можно попробовать залогиниться на клиенте под любым из юзеров и зайти в \\ad\share. Тут всё ясно. Но как рулить правами на отдельные вложенные файлы и папки? Тут нам помогут NTFS-права, которые как раз-таки и применяются отдельно к каждому файлу и каждой папке. В итоге на любой объект будет действовать два набора прав - права общего доступа и NTFS-права. Наименьшее из прав будет результирующим, то есть мы дали в общем доступе правам всем на всё и если теперь запретим NTFS-правами запись всем в определённую папку, то писать в эту папку никто не сможет, хоть в общем доступе и записано обратное. Итак у нас есть на сервере папка vip-документы, пусть она будет только для директора и бухгалтерии. На сервере заходим в свойства этой папки на вкладку Безопасность, жмём Изменить.
Удаляем из списка группы Пользователи и Пользователи домена.
Ага. Низзя. Винда доступно объяснила, что удаление невозможно из-за того, что эти права унаследованы, а не применены напрямую. Ну делаем, что сказано - в свойствах папки на вкладке Безопасность жмём Дополнительно > Изменить, снимаем галочку "Добавить разрешения, наследуемые от родительских объектов".
Тут жмём копировать, чтобы не удалилось ничего лишнего - сами удалим, что надо. ОК, ОК... Возвращаемся туда, где нам запретили удалить ненужные группы (Безопасность > Изменить) и спокойно удаляем группы Пользователи и Пользователи домена. Взамен добавим группу Бухгалтерия и гендиректора. Всё вбивается просто ручками.
Для верности после ввода можно жать Проверить имена.
Ставим директору и буху полный доступ. ОК.
Теперь, если попробуем зайти в папку с клиента под пользователем, к примеру, man-s (один из наших менеджеров), то получим вот такое сообщение:
Примерно так. Ну и до кучи создадим в папке SHARE файл "рабочий регламент.txt", напишем туда чего-нибудь и изменим NTFS-права на только чтение для всех (схема та же - снимаем галочку про наследование, убираем лишние группы, группе Пользователи домена даём право на чтение, гендиру - полный доступ). Теперь попытаемся изменить его под учёткой, скажем, бухгалтериши. Ожидаемо получаем ошибку:
Не знаю, почему написано "создать", а не "изменить"... Хер с ним. Суть одна - поменять файл под левой учёткой мы не сможем. Пытливые умы могут попытаться сделать то же под гендиром и убедиться, что всё получается.
Ну и надо бы хоть какую-то пользу извлечь из наших подразделений. Несколько раз до этого я уже упоминал о групповых политиках - самое время познакомиться с ними поближе. Самое простое и частоиспользуемое употребление, которое первое всплывает в голове - логон-скрипты. Смысл прост - на сервере создаёте скрипт, прописываете его опредённым клиентам как сценарий, выполняемый при входе в систему (или при выходе), и вот рутинные действия типа подключения нового сетевого диска на каждой машине, прописывания настроек прокси и т.п. легко автоматизированы. И не приходится бегать и делать всё ручками. Может не такое уж мы и быдло?.. Да неее. Конечно, всё ещё быдло. Работаем дальше.
Администрирование > Управление групповой политикой. Тыкаем, куда показано на скрине.
Обзовём наш новый объект logon. Затем жмём на подразделение Бухгалтерия и выбираем "Связать существующий объект GPO" и там видим наш logon. И повторим для Отдела продаж.
Мы создали объект групповой политики. Теперь надо прописать, что же он будет задавать (пока что он пустой - политики там не заданы). В Объектах групповой политики жмём на наш logon и выбираем Изменить.
Отрывается редактор, в котором идём сюда: Конфигурация пользователя > Политики > Конфигурация Windows > Сценарии (вход/выход из системы). Наверное логично будет перед тем, как задавать этот параметр, создать собственно скрипт для логона. Заходим в эту папку - C:\Windows\SYSVOL\sysvol\stado.local\scripts. Это стандартная расшаренная папка, доступная всем для чтения. Создаём файл share_disk.cmd (в качестве логон-скриптов нельзя использовать bat-файлы, только cmd) со следующим содержимым:
net use z: \\ad\share
Это собственно и есть подключение диска на букву Z. Путь к этому файлу и пропишем Сценарии (вход/выход из системы) > Вход в систему:
Не забываем, что прописывать надо сетевой путь, а не локальный, так как клиенты будут обращаться именно к файлу \\ad\netlogon\share_disk.cmd, а не к C:\Windows\SYSVOL\sysvol\stado.local\scripts\share_disk.cmd.
Вот. Теперь при входе в систему всем бухам и манагерам будет подключен сетевой диск. Вообще-то это одноразовая процедура, так как однажды подключённый сетевой диск будет подключаться каждый раз при входе, если его явно не отключить руками, так что скрипт нужен только для разового выполнения, после чего его можно убрать из сценариев входа. С другой стороны, если скрипт выполнится несколько раз, ничего страшного не произойдёт - вывод сообщений об ошибках мы отключили (@echo off), а ресурсов лишнее выполнение скрипта у вас не отъест.
Ну и раз такая пьянка, то сделаем ещё что-нибудь. Например, отключим для всех наших юзеров автозапуск со сменных носителей - один из основных источников угроз безопасности (кому не попадалась флешка с автораном, запускающим какую-нибудь какаху?). В том же редакторе, где мы выставляли логон-скрипт идём по следующему пути: Конфигурация пользователя > Политики > Административные шаблоны > Компоненты Windows > Политики автозапуска > Отключить автозапуск. Включаем параметр и выставляем значение "Все устройства". Всё.
Кому любопытно, тот может самостоятельно потыкаться по политикам. Там много интересного и нужного. А мне пожалуй больше сказать нечего.
Комментариев нет:
Отправить комментарий