|
|
|
от Dan DiNicolo |
|
|
Добро пожаловать в статью 17 моей серии. Статья этой недели посвящена продолжению темы «Групповые политики», а также рассмотрению вопросов распространения программного обеспечения и концепции доверительных отношений в Active Directory. Мы детально рассмотрим вопросы связывания групповых политик, делегирования, наследования и фильтрации, а также дополнительные настройки при распространении программного обеспечения и, наконец, внешние и внутренние доверительные отношения в Active Directory. На следующей неделе мы продолжим изучение материалов, относящихся к экзамену 70-217, таких как протокол Kerberos, репликация, поддержка базы данных AD и поддержка operations masters (Хозяев операций). В данной статье мы рассмотрим следующие темы:
Групповые политики (Часть 2) Эта раздел завершает обсуждение групповых политик, которое было начато на предыдущей неделе. Объект Групповая политика храниться в Active Directory и он обязательно связан, по крайней мере, еще с одним объектом, таким как сайт, домен или OU. Однако, GRO (объект Групповая Политика) может быть применен и к нескольким объектам и это возможность упоминается как linking (связывание). Например, вы можете связать объект Групповая политика, уже связанный с OU Sales, с другой OU (например, Marketing), как это показано ниже:
Хотя можно связать GRO из одного домена с объектом в другом домене, это не рекомендуется, вследствие того, что контроллер домена из домена, в котором GRO храниться, обязательно должен быть доступен в ходе применения политики (например, при входе в систему). Возможность создавать GRO, редактировать GRO и связывать его может контролироваться при помощи разрешений на доступ к объекту, членства в группах, и Delegation of Control Wizard (мастера делегирования контроля). Для создания GRO пользователь должен быть членом встроенной группы, называемой Group Policy Creator Owner (владелец-создатель групповой политики), в которую, по умолчанию, входят только администраторы домена, как это показано на рисунке, расположенном ниже:
Для управления связыванием групповых политик на объекте (добавление, удаление и т.д.), пользователь должен иметь следующие разрешения на доступ к объекту: gPLink и gPOptions Read и Write. Проще всего эти разрешения можно дать, используя мастер делегирования контроля. Нужно выбрать опции, как показано на рисунке, расположенном ниже:
Возможность редактировать установки GRO контролируется при помощи ACL (список контроля доступа) на самом GRO. Не перепутайте этот список с ACL, относящийся к объекту, к которому применена GRO. Вы можете увидеть ACL, относящийся к GRO, щелкнув на кнопку Properties, когда выберете соответствующую GRO, как показано на рисунке, расположенном ниже:
Давая кому-либо Read и Write разрешения на доступ к GRO (как минимум), вы даете этому пользователю возможность редактировать настройки GRO. Возможность контролировать тех, кто имеет право редактировать GRO, но также тех, кто может связывать и создавать GRO, является мощной возможностью, дающей администратору максимум гибкости в делегировании администрирования групповых политик. Наследование Групповых политик Как отмечалось неоднократно в предыдущих статьях, групповые политики могут быть применены на уровнях: Локальном, Сайта, Домена и OU. Этот порядок контролирует, какие установки политики, в конце концов, будут применены к пользователю или компьютеру. Помните, что все установки сливаются вместе по умолчания и, в случае конфликта, последняя из них будет применена к объекту. Вы можете заметить одно, на первый взгляд, нелогичное обстоятельство – то, что администратор на уровне OU может переназначить установки, сделанные администратором домена. И это действительно так – в конечном счете установки на уровне OU переписывают установки политик доменного уровня в случае их конфликта. Однако это поведение политик может контролироваться при помощи двух специальных установок, Block Inheritance (блокирование наследования) и No Override (не перекрывать). Установка Блокирование наследования выглядит наиболее сильной. Если администратор OU применит эту установку к своей OU, тогда все установки политик, которые установлены на более «высоких» уровнях будут полностью блокированы по умолчанию. Это означает, что будут отвергнуты все наследуемые установки политик уровня сайта, домена и родительских OU. Заметьте, что это очень действенное свойство, так как, например, если вы не хотите, чтобы какие-либо политики доменного уровня были применены к особой категории пользователей, то вы можете просто блокировать наследование политик на OU, объединяющей этих пользователей, как это показано на рисунке, приведенном ниже:
Те, кого смущают эти возможности установки Блокировать наследование, не должны отчаиваться. Другая установка, которая может быть применена – это Не перекрывать и она всегда сильнее, чем Блокировать наследование. Так, если вы создадите политику на уровне сайта и установите в ней флажок Не перекрывать и администратор любой OU установит Блокировать наследование, установки, содержащиеся в политике сайта, будут применяться всегда. Заметьте, что другие политики, без установки Не перекрывать, будут продолжать блокироваться в данном сценарии. Установка Не перекрывать выполняется после нажатия кнопки Options (опции) при выделении соответствующей GRO, после чего выводится следующее окно:
И последнее, что вам необходимо знать о групповых политиках – это то, что они могут фильтроваться. Это означает, что вы можете точно контролировать, к каким объектам будет применен GRO, устанавливая соответствующие разрешения в ACL данной политики. Например, вы применили политику к некоторой OU и хотите, чтобы она действовала на всех пользователей OU, за исключением пользователя, которого зовут SalesAdmin. По умолчанию, групповая политика всегда применяется к группе Authenticated Users (аутентифицированные пользователи), которая имеет разрешения Apply Group Policy (применить групповую политику) и Read (читать) с установкой Allow (разрешить). Для того чтобы вывести пользователя SalesAdmin из-под действия политики, мы можем предотвратить действие установок GRO, дав пользователю разрешение Deny Apply Group Policy (запретить применение групповой политики), как показано на рисунке, приведенном ниже:
Не стоит особо увлекаться фильтрацией политик, так как это может затруднить выявление неисправностей при применении групповых политик. Вместе с тем, вы должны осознавать, что фильтрация является мощным инструментом для контроля применения политик к пользователям и группам, так как групповые политики не могут быть применены к этим типам объектов напрямую. Внедрение программного обеспечения через групповые политики Так как основы данной темы были рассмотрены в предыдущих статьях серии, наше внимание теперь будет направлено на более углубленное ее изучение. В целях повторения вспомним основы распространения программного обеспечения через групповые политики: В среде Active Directory групповые политики позволяют вам распространять программное обеспечение пользователям и компьютерам, используя переупаковывающий файловый формат – msi. Когда приложение распространяется через групповую политику, пользователю не требуется специальных прав, так как приложение устанавливается при повышенных привилегиях самой политики. Если производитель не предоставляет файл msi для своего приложения, вы можете использовать специальную переупаковывающую программу, такую как WinInstall LE (которая находится на установочном компакт-диске Windows 2000), для его создания. Второй важный момент при распространении программ через групповые политики – это то, как мы его распространяем. Есть две возможности – либо Assign (назначить) либо Publish (опубликовать) их. Программы могут быть как опубликованы, так и назначены пользователям. В случае их назначения приложение начинает «следовать» за пользователем, независимо от того, на каком компьютере он входит в сеть. Иконка программы появляется в стартовом меню, но программа не устанавливается до тех пор, пока пользователь не «кликнет» по иконке. Когда программа назначается компьютеру, она устанавливается на компьютер при его следующей перезагрузке, и становится доступной всем пользователям этого компьютера. Когда программа публикуется (что может быть сделано только для пользователей, но никогда – для компьютеров), она становиться доступной для установки при помощи программы Add/Remove programs, или при обращении к соответствующему документу (когда пользователь «кликнет» по документу, формат которого ассоциируется с этой программой). Опубликование программы делает ее доступной для пользователей, но у вас не должно создаться иллюзии, что оно уже является установленным. Приложение может быть также опубликовано с использованием файла с расширением .zap, если нет файла .msi или его невозможно создать. Заметьте, однако, что при использовании файла .zap, у пользователя должен быть соответствующий уровень привилегий, достаточный для установки приложения. Также заметьте, что внедрение программного обеспечения через групповые политики доступно только для систем с OS Windows 2000 и не могут быть применены, если пользователь пользуется компьютером с Windows 98, например. Раздел Software Setting (установка программного обеспечения) групповой политики, где и производится назначение или опубликование программ, показано на рисунке, расположенном ниже:
Когда приложение внедряется через групповую политику, первая опция, которая должна быть выбрана – это будет ли ваше приложение опубликовано или назначено, как показано ниже:
Дополнительные свойства для внедрения программного обеспечения могут быть настроены, если вы выбираете опцию Advanced published or assigned (Дополнительные настройки опубликования или назначения), или позднее, изменяя свойства внедряемого пакета. Дополнительные свойства позволяют вам контролировать многие параметры, имеющие отношение к распространяемому приложению, включая такие, как добавление обновлений и патчей, модификация, а также удаление пакетов. Есть шесть вкладок дополнительных свойств внедряемого приложения и вы должны быть хорошо знакомы с ними. Вкладка General (общая) содержит основную информацию об объекте (такую как номер версии и т.д.), в то время как вкладка Security (безопасность) содержит ACL объекта. Вкладка Deployment (внедрение), показанная ниже, контролирует, было ли приложение опубликовано или назначено (эта настройка может быть изменена). Если опубликовано, вы можете контролировать, будет или нет приложение устанавливаться при обращении к файлам, ассоциирующимся с данным приложением (эта опция будет «залита» серым, если вы выбрали Назначить приложение).
Заметьте, что существует опция To uninstall the application when it falls out of the scope of management (Удалять приложение, если оно выходит из сферы управления). Если она выбрана и групповая политика, которая установила это приложение, больше не применяется (например, если объекты пользователь или компьютер были перемещены), тогда приложение будет автоматически удалено. Опция Installation user interface options (установка опций пользовательского интерфейса) позволяет вам контролировать как много взаимодействий пользователь будет иметь в процессе установки. Вкладка Upgrades (обновления), изображенная на рисунке внизу, позволяет вам автоматизировать установку патчей и обновлений (таких, как новейшие версии) в приложения, которые уже внедрены через групповую политику. Если обновление должно выполняться в обязательном порядке, выбирается опция required (обязательный), и тогда обновление внедряется сразу и пользователь сможет использовать только новую версию приложения. Если это не обязательное требование, тогда пользователь может использовать как старую, так и новую версию. Это может быть потенциально полезным, если новое приложение не имеет обратной совместимости (не работает с документами, созданными в старой версии программы, например).
Вкладка Categories (категории) позволяет вам контролировать то, каким образом приложение будет представлено в программе Add/Remove. Например, вы можете создать категории для каждого типа приложений, таких как графические приложения, программы для работы с текстом и т.д. Эта вкладка позволит вам группировать вновь публикуемые приложения в эти категории для того, чтобы упростить пользователю процесс выбора необходимых ему программ. И, наконец, вкладка Modifications (изменения), показанная ниже, позволяет вам дальнейшую настройку пакета для пользователей со специфическими потребностями. Например, вы хотите внедрить различающиеся по языку словари для пользователей в разных офисах, и применяете модифицирование пакета. Модифицирование выполняется в виде файла с расширением .mst (также известном как файл трансформации). Есть специальная утилита для создания файлов .mst, которая содержится в resource kit (наборе инструментов) Microsoft Office 2000.
Леса и доверительные отношения в Active Directory Как отмечалось в предыдущих статьях, все домены в лесу Active Directory способны взаимодействовать друг с другом благодаря природе доверительных отношений, которые создаются между ними автоматически. Транзитивные двунаправленные доверительные отношения существуют между каждым поддоменом и его родительским доменом, а также транзитивные двунаправленные доверительные отношения существуют между корнями всех деревьев и корнем леса. Нужно заметить, что в некоторых случаях необходимо создавать дополнительные доверительные отношения, как внутри так и вне вашего леса. (Напомню, что транзитивность означает, что если а доверяет b, а b доверяет с, это означает, что а доверяет с. В случае нетранзитивных доверительных отношений (которые существуют в среде NT 4) это отношение не выполняется). Например, у вас есть домен, который продолжает работать в среде NT 4 и вы хотите, чтобы он мог иметь доступ к домену в вашей структуре Active Directory. Для этого требуется создать внешние доверительные отношения, которые очень похожи на доверительные отношения, с которыми вы знакомы по работе в NT 4. Эти отношения являются однонаправленными и нетранзитивными, что означает, что они дают возможность для доступа только к одному домену. Для данного сценария схема доверительных отношений будет выглядеть так:
В данном примере пользователи из домена NT4DOMAIN будут иметь доступ к ресурсам только в домене asia.win2000trainer.com (доступ осуществляется не по, а против стрелки доверительного отношения). Конечно, могут быть созданы и двунаправленные отношения между этими двумя доменами, тогда пользователи из домена asia.win2000trainer.com смогут иметь доступ к ресурсам NT4DOMAIN. Но эти отношения доверия также останутся нетранзитивными, а значит, не распространяют свое действие на другие домены. Так, если вам потребуется, чтобы пользователи из NT4DOMAIN имели доступ к ресурсам всех трех доменов леса, вам необходимо будет установить доверительные отношения с каждым из них. Инструмент, используемый для создания внешних доверительных отношений, это оснастка Active Directory Domains and Trusts (домены и доверительные отношения в Active Directory). Этот инструмент используется для создания, управления и контроля доверительных отношений между доменами. Заметьте, что оснастка показывает как внутренние так и внешние доверительные отношения, которые существуют в Active Directory. Получив доступ к свойствам домена, вы можете увидеть все существующие доверительные отношения на вкладке Trusts, как показано ниже:
На экран выводится имя домена, тип доверительных отношений (внутренние, внешние), а также являются ли они транзитивными или нет. Как и в NT 4, для целей безопасности внешние доверительные отношения устанавливаются при участии обоих доменов. Заметьте также, что внешние доверительные отношения могут связывать домен Windows 2000 с доменами NT 4, а также домены Windows 2000 из разных лесов. Второй тип доверительных отношений, который может быть создан, часто упоминается как сокращенные доверительные отношения. Этот тип доверия создается для сокращения пути, который приходится преодолевать в целях аутентификации. Например, в лесу, изображенном на рисунке, расположенном ниже, для доступа из домена europe.win2000trainer.com в домен china.asia.win2000trainer.com, необходимо преодолеть 3 доверительных отношения:
Если пользователям из домена europe.win2000trainer.com необходимо регулярно получать доступ к ресурсам по данному пути, то имеет смысл создать сокращенные доверительные отношения (как показано на рисунке, расположенном ниже), для уменьшения числа доверительных отношений, которые необходимо пересекать. Заметьте, что сокращенные доверительные отношения являются двунаправленными и транзитивными и создаются также в оснастке Active Directory Domain and Trust.
Для контроля доверительных отношений вы можете использовать кнопку Verify (проверить) в оснастке Active Directory Domain and Trusts, когда рассматриваемый вами домен выделен в списке:
Кроме того, в resource kit (наборе инструментов) Windows 2000 включена утилита командной строки для проверки доверительных отношений – Netdom.exe. На этом заканчивается статья этой недели. На следующей мы продолжим рассмотрение протокола Kerberos, репликации, поддержки базы данных AD и хозяев операций. Спасибо всем, кто поддерживает данную серию. Как всегда обращайтесь ко мне с вопросами и комментариями, но помните, что технические вопросы я прошу присылать на мою доску объявлений для общего обсуждения. До следующей недели и успехов вам в учебе.
Дэн
|
