Я планирую макет установки Active Directory для нашей организации. Я изучаю возможность использования групповой политики для обеспечения соблюдения определенных параметров, повышения безопасности на наших настольных компьютерах и серверах и обеспечения более согласованного взаимодействия с пользователем по сравнению с нашим стандартным образом компьютера. У нас будет сочетание серверов Windows XP, Windows 7 Pro, Windows Server 2003, Windows Server 2008 R2 Standard, Macintosh OS X (10.6) и различных серверов Linux (CentOS и Ubuntu) в нашей среде.
Мы будем очень благодарны за любую помощь и идеи, которые у вас есть. Мне интересно поучиться у вас и вашего опыта, чтобы помочь сделать нашу миграцию успешной - особенно такой, что нам не нужно проходить и переделывать все через год.
Задний план:
Я использую групповую политику сильно на сайтах моих клиентов с середины 2000 года, когда я начал развертывать клиенты Windows 2000 Server и Windows 2000 Professional. Групповая политика - одна из наиболее привлекательных функций платформы Windows Server / Active Directory по сравнению с другими Samba и другими механизмами единого входа, совместимыми с клиентскими операционными системами Windows.
Асинхронная обработка политик обеспечивает недетерминированный опыт. Он был отключен по умолчанию в Windows 2000 Processional, но включен по умолчанию во всех более поздних версиях клиентской операционной системы Windows. Я настоятельно рекомендую вернуть процесс обратно в синхронный режим, чтобы обеспечить детерминированный опыт.
Огромное значение имеет понимание того, как параметры в объектах групповой политики выбираются и применяются к компьютерам и пользователям. Алгоритм действительно очень прост (а «Наследование блока» и «Без переопределения» лишь немного усложняют алгоритм). Большинство проблем применения политик в конечном итоге связаны с несоответствием понимания системным администратором алгоритма, используемого для применения групповой политики, и того, что на самом деле делает ОС. Полагаться на такие инструменты, как RSoP или GPRESULT, вместо того, чтобы иметь четкое представление о том, как работает эта функция, - плохая идея.
Не забывайте ссылки GPO на уровне сайта. Они могут быть очень и очень кстати. Будьте осторожны с настройками, которые могут вызвать серьезные события (например, установка программного обеспечения с обязательным удалением, когда компьютеры «выпадают из сферы действия») при перемещении портативных компьютеров между сайтами.
Планируйте и тестируйте в лабораторных подразделениях и на тестовых компьютерах перед развертыванием в производственной среде, особенно при установке программного обеспечения. Тестируйте, тестируйте, тестируйте и снова тестируйте. Групповая политика может позволить вам очень и очень легко повредить конфигурацию сотен или тысяч компьютеров, если вы сделаете ошибку.
Не смотрите на групповую политику как на средство безопасности как таковое. Групповая политика может помочь в стратегии «глубокой защиты» (включение таких функций, как AppLocker, обеспечение членства в группах и т. Д.), Но если кто-то получит права «Администратор» на машине, им будет легко «убить» группу. Политика на этой машине.
Убедитесь, что вы понимаете, как работают «Наследование блоков», «Без переопределения», а также WMI и фильтрация групп безопасности. Эти функции могут позволить вам управлять сценариями, которые не могут быть обработаны простым связыванием GPO в OU. Старайтесь не злоупотреблять этими функциями, потому что они могут быть не интуитивно понятными для обратного проектирования через несколько месяцев или для понимания другими системными администраторами.
Перед внесением изменений сделайте резервную копию важных объектов групповой политики. Инструмент GPMC добавил эту функциональность, и это очень и очень удобно. Вы в любом случае должны делать резервные копии состояния системы AD, но восстановление отдельного объекта групповой политики из резервной копии с помощью GPMC много удобнее, чем восстановление состояния системы.
Я часто пользуюсь сценариями, которые работают как «лазейка». Клиенты могут применять сценарии, если они не являются членами данной группы. Последняя строка сценария помещает клиента в эту группу, так что при следующей загрузке клиент больше не выполняет сценарий. Это очень удобное поведение.
Немного. У меня есть разные клиенты с разными «версиями» моего «стиля» приложения групповой политики. По сути, я бы не стал «делать что-то другое», но я работаю над тем, чтобы все нормализовалось в одну очень похожую конфигурацию. Для меня это просто вопрос настройки «стиля» объектов групповой политики, а не внесения каких-либо широких, радикальных изменений. В основном изменения, которые мне пришлось внести, были результатом недостаточного тестирования перед запуском в производство. Я уже упоминал, что вам следует делать тесты рано и часто?
Так же, как я бы разделил разные классы пользователей или клиентских компьютеров. Я разделяю клиентские и серверные компьютеры на разные подразделения и связываю с ними разные объекты групповой политики. Серверы с разными ролями могут быть дополнительно разделены (или помещены в группы безопасности и приложение GPO отфильтровано). У меня есть общие объекты групповой политики, которые применяются к обоим типам компьютеров (обычно с несколькими избранными настройками в них).
Фильтрация WMI - это один из способов обработки различных версий Windows. Он работает нормально, но лично мне это не нравится.
Обычно я развертываю сценарий запуска (который, к сожалению, написал во время работы с клиентами, поэтому я не могу поделиться им здесь), чтобы определить версию Windows клиентов групповой политики (а также их разрядность 32/64 и то, они работают с нуля или работают на данном гипервизоре) для заполнения групп, чтобы я мог использовать фильтрацию группы безопасности, а не фильтрацию WMI. Поскольку фильтрация WMI атомарна только для объекта групповой политики, тогда как я могу использовать фильтрацию групп безопасности в отдельных установках программного обеспечения внутри объекта групповой политики, я предпочитаю фильтрацию групп безопасности.
У меня нет опыта работы с клиентским программным обеспечением, позволяющим клиентам, отличным от Windows, использовать групповую политику, поэтому я вообще не могу с этим разговаривать.
Я пришел из "старой школы", поэтому я научился разрабатывать Active Directory на основе рекомендации, сделанные Microsoft «в свое время». Я очень серьезно думаю о групповой политике, когда выстраиваю структуру своего подразделения (вместе с делегированием управления, что является моей первой проблемой в отношении структуры подразделения).
Лично я предпочитаю иметь как можно меньше объектов групповой политики для выполнения работы без повторения общих настроек в нескольких объектах групповой политики. Я максимально ограниченно использую «Наследование блока», «Без переопределения» и фильтрацию групп безопасности (особенно с разрешениями «Запретить»). Я стараюсь называть объекты групповой политики многословными, чтобы они были «самодокументированными». я никогда изменить объекты групповой политики по умолчанию, которые поставляются «из коробки» с Active Directory, чтобы я мог отключить все другие объекты групповой политики в «аварийной» ситуации и вернуть продукт к «стандартному» поведению.
Это моя общая стратегия, и она мне хорошо сработала. Я могу связать один и тот же объект групповой политики в нескольких местах (например, объект групповой политики с именем «Общие параметры для рядовых серверов и компьютеров контроллеров домена», который связан в подразделении «Рядовые серверы» и в подразделении «Контроллеры домена» по умолчанию). Затем я бы связал дополнительные объекты групповой политики, которые имеют более конкретные настройки, по мере того, как я опускаюсь в свою иерархию подразделений. Связывание «глупого» количества объектов групповой политики (многих десятков или сотен) повлияет на производительность. У меня есть клиенты с клиентами, которые связывают от 7 до 12 объектов групповой политики без снижения производительности.
Некоторые из модулей расширения на стороне клиента (CSE) групповой политики могут работать медленно. В некоторых случаях (например, при перенаправлении папок или политике установки программного обеспечения) это может быть только разовое замедление. В других случаях (например, IE Policy в Windows XP SP3) он может добавлять пару секунд на каждый вход в систему. В общем, постарайтесь быть консервативным и связывайте как можно меньше объектов групповой политики. Запустите столько скриптов, сколько вам нужно (они действительно могут складываться, если вы обрабатываете их синхронно). Время входа в систему должно быть частью вашего тестирования.
В файлах REGISTRY.POL разницы нет. создается файлами ADM по сравнению с файлами ADMX. Если вы собираетесь управлять групповой политикой из Windows 2003 или Windows XP, вам необходимо хранить файлы ADM. Если вы собираетесь ограничить администрирование GPO Windows Vista или более новыми ОС, вы можете отказаться от файлов ADM. Лично я не беспокоился об этом, но тогда мой самый большой SYSVOL составляет всего около 400 МБ. Если бы у меня были сотни объектов групповой политики, я бы, вероятно, захотел как можно скорее перейти от файлов ADM.
Если вам нужна функция, которую он предоставляет, это абсолютно хорошая идея. Есть несколько сценариев, которые без него невозможно настроить. Обработка политики петли работает нормально, если вы понимаете, как это работает. Это очень полезно для той цели, для которой оно предназначено (применение согласованных пользовательских настроек к компьютерам независимо от того, вошел ли пользователь в систему).
Это связано с вопросом о времени входа в систему. Вы можете протестировать его и увидеть в своей среде, но, честно говоря, я не заметил разницы в производительности. Я не беспокоюсь об этом на сайтах моих клиентов.