Управление терминальными серверами в среде AD

Опубликована: 17.01.2005
При работе в среде AD вы имеете возможность централизовать конфигурацию ваших терминальных серверов, облегчая ввод новых серверов в ферму. В этом разделе мы сосредоточимся на инструментах, используемых для настройки и управления терминальными серверами в AD.

Active Directory Users and Computers

Active Directory Users and Computers - это административная утилита, используемая для управления OU, пользователями, компьютерами и группами в AD. На следующем рисунке показан интерфейс Active Directory Users and Computers.

В конфигурации по умолчанию объекты AD разделены в 5 основных категорий:

Если вы управляете небольшим или средним доменом, этих контейнеров достаточно для удовлетворения ваших нужд. Однако, если вам необходимо организовать ваших пользователей, вы можете создать новые контейнеры OU для хранения объектов. Затем вы применяете разрешения к этим OU, чтобы группы администраторов могли управлять пользователями и компьютерами в своих собственных OU.

При интеграции терминальных серверов в AD, желательно создать новый OU специально для терминальных серверов. Это позволит применять объекты групповых политик (GPO) ко всем серверам этого OU, не заботясь о добавлении серверов в группу безопасности, чтобы они получали настройки из политик. Исключение из этого пожелания - если вы используете исключительно тонкие клиенты; в этом случае вам не нужно создавать отдельные GPO для рабочих станций и терминальных серверов.

Group Policy Management Console

В WS2K3 включен новый инструмент для управления групповыми политиками — Консоль управления политиками (Group Policy Management Console, GPMC). Используя GPMC, вы можете создавать и редактировать GPOs; связывать GPO с OU, сайтами и доменами; настраивать безопасность; делегировать администрирование; делать резервные копии и восстанавливать GPO; создавать отчеты в формате HTML; и даже запускать сценарии Resultant Set of Policy для помощи в проектировании ваших GPO.

По умолчанию GPMC не инсталлируется. Вы можете загрузить ее отсюда: http://www.microsoft.com/windowsserver2003/gpmc/default.mspx.

Настройка терминальных серверов при помощи групповых политик

После того, как вы подняли AD и добавили в домен терминальные серверы, вы готовы начать проектировать свои GPO для конфигурирования терминальных серверов и пользовательских сеансов. В главе 2 содержался краткий обзор политик, которые вы можете сконфигурировать для серверов. В предыдущих разделах я упоминал, что вы можете использовать GPO для конфигурирования настроек пользователей и сеансов, например, тайм-аутов, редиректа ресурсов и т.д. Вы также можете использовать GPO для управления пользовательским интерфейсом Windows и для ограничения доступа к инструментам и функциям, которые злонамеренные пользователи могут использовать для дестабилизации работы сервера.

Настройки интерфейса пользователя

Большинство настроек, доступных в GPO, предназначены для конфигурирования и блокировки интерфейса пользователя. Это весьма скользкая тема, поскольку пользователи часто привыкли использовать особенности Windows, которые администраторы часто удаляют или запрещают использовать на терминальных серверах (например, командная строка, команда Run, Task Manager и т.п.). Я рекомендую прочесть статью Microsoft “How to Lock Down a Win2K Terminal Server Session”. Затем вы можете добавлять или удалять ограничения в зависимости от требований пользователей.

Ниже приведен список политик, которые рекомендует Microsoft (настройки разделены на Computer Configuration и User Configuration):

Настройки Computer Configuration:

Настройки User Configuration:

Очевидно, что если вы используете все эти политики, то получите крайне строгую среду, почти не пригодную к использованию. Например, Microsoft рекомендует удалить команду Map Network Drive, но если вы находитесь в распределенной среде, ваши пользователи могут потребовать этой возможности для доступа к своим документам. Тем не менее этот список может служить хорошей отправной точкой.

Я рекомендую начать с крайне ограничительной политики, а затем протестировать и при необходимости разрешить отдельные настройки. Вы не должны полагаться только на политики при защите вашего сервера, поскольку они оставляют множество лазеек для злонамеренных пользователей. Например, если вы используете Prevent access to drives in My Computer в качестве единственного метода защиты файлов на сервере, злоумышленник может легко создать пакетный файл. Вместо этого вы должны применить ограничения NTFS для защиты файловой системы и использовать политику Prevent access to drives in My Computer для предотвращения использования диска C сервера в качестве диска C своего клиентского устройства. Если вы запускаете сервер в режиме Full Security, то большинство ключевых областей файловой системы и реестра по умолчанию защищены.

Вам следует быть осторожными, создавая разные политики для пользователей и системных администраторов. Очевидно, что администраторам требуются некоторые функции, которые не нужны пользователям. Для создания отдельных политик, создайте два объекта GPO, один для пользователей, которые включает все ограничения, которые вы хотите реализовать, а второй - для администраторов, в котором ограничения запрещены. Установите делегирование на пользовательскую политику для применения ее к Authenticated Users, а администраторскую политику примените только к доменной группе, содержащей учетные записи администраторов. Наконец, поместите в порядке применения администраторскую политику перед пользовательской.

Ограниченные группы

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

Ограниченные группы (Restricted Groups) позволяют вам управлять членами локальной машинной группы через доменные GPO. Тогда при добавлении в домен нового терминального сервера, сервер немедленно наследует надлежащие доменные группы в свою группу Remote Desktop Users. Таким же способом вы можете управлять локальной группой Administrators.

Порядок обработки политик

Очень важен порядок применения объектов GPO. Поскольку для данного пользователя или компьютера у вас может быть несколько политик, в конечном счете эффект настроек определяет результирующий набор политик (Resultant Set of Policy). Чтобы определить конечные настройки, которые применяются к пользователям, вы должны просмотреть все GPO, которые применяются к этому пользователю. GPO применяются в фиксированном порядке: локальные, сайтовые, доменные, OU. Машинные и пользовательские настройки применяются раздельно, хотя они оба идут из одного GPO.

Для понимания порядка обработки GPO, давайте взглянем на инфраструктуру теоретического домена и проследим применение политик. На рисунке показан примерный домен и его GPO. Для простоты я применил только по одному GPO на каждом уровне. В большинстве случаев у вас будет одновременно несколько GPO на уровнях сайта, домена и OU. Эти GPO будут обрабатываться все, чтобы получить Результирующий набор политик.

Начнем с обработки GPO при загрузке компьютера computer1. Во время загрузки настройки безопасности применяются к этому компьютеру в следующем порядке:

  1. Local — Применяются настройки Computer Configuration из локальной политики cComputer1 Local Policy.
  2. Site — Применяются настройки Computer Configuration из USA Site Policy.
  3. Domain — Применяются настройки Computer Configuration из Domain Policy.
  4. OU — Применяются настройки Computer Configuration из Workstation OU Policy. Политики OU определяются OU, в которой находится объект. В нашем случае computer1 находится в OU "Workstations", поэтому обрабатываются политики, связанные с этой OU.

Теперь, когда computer1 имеет полную конфигурацию, заставим на нем зарегистрироваться пользователя Greg, чтобы обработались политики User Configuration:

  1. Local — Применяются настройки User Configuration из Computer1 Local Policy
  2. Site — Применяются настройки User Configuration из USA Site Policy
  3. Domain — Применяются настройки User Configuration из Domain Policy
  4. OU — Применяются настройки User Configuration из Users OU Policy для OU "Users". В стандартном режиме обработки, Грег всегда получит свою конфигурацию User Configuration из политики, независимо от того, в какой OU находится компьютер, на котором он регистрируется.

В стандартном режиме обработки, поскольку в OU "Workstation" нет пользователей, политика User Configuration из Workstation OU Policy никогда не применяется. Кроме того, в стандартном режиме обработки, Грег получит одинаковый результирующий набор пользовательских политик независимо от того, на каком компьютере он регистрируется. Эта особенность важна в больших доменах со множеством рабочих станций, где Грег может использовать компьютеры из других OU. Однако, если вы хотите, чтобы Грег получил более ограничительную политику при регистрации на некотором компьютере (например, на терминальном сервере), вам необходимо реализовать обратную обработку политик.

Обратный порядок обработки политик

Обратный порядок обработки политик позволяет получить преимущества настроек User Configuration из GPO, связанного с OU, которая содержит компьютер. Как показано на следующем рисунке, есть два режима обратной обработки: Замена (Replace) и Слияние (Merge). Режим слияния предписывает системе сначала применить User Configuration из политики OU "Users" (стандартный режим обработки), затем применить User Configuration из политики OU "Computers". Результирующий набор политик будет представлять собой комбинацию обоих наборов GPO. Режим замены предписывает системе целиком игнорировать объекты GPO из OU "Users" и применять только настройки User Configuration из политики OU "Computers".

В нашем примере мы можем включить обратную обработку политик в режиме слияния для терминального сервера TS01. В этом сценарии Computer Configuration применяется как обычно, но когда Грег подключается к TS01, его User Configuration применяется в следующем порядке:

  1. Local — Применяются настройки User Configuration из политики Computer1 Local Policy
  2. Site — Применяются настройки User Configuration из политики USA Site Policy
  3. Domain — Применяются настройки User Configuration из политики Domain Policy
  4. OU — Применяются настройки User Configuration из политики Users OU Policy для OU "Users"
  5. OU Loopback — Применяются настройки User Configuration из политики TS OU Policy из OU "Terminal Servers"

В этом режиме Грег получает настройки прокси для его Internet Explorer из политики "Users OU Policy", но не имеет доступа к команде Shut Down в меню Start, т.к. она удалена политикой "TS OU Policy". Режим слияния имеет преимущество в том, что можно поместить глобальные настройки в политику "Users OU Policy", а запрещения применять только в политике "TS OU Policy". Недостатком этого режима является то, что вам необходимо следить за пользовательскими настройками в двух объектах GPO.

В режиме замены, User Configuration из политики "Users OU Policy" игнорируется :

  1. Local — Применяются настройки User Configuration из Computer1 Local Policy
  2. Site — Применяются настройки User Configuration из USA Site Policy
  3. Domain — Применяются настройки User Configuration из Domain Policy
  4. OU Loopback — Применяются настройки User Configuration из TS OU Policy

Этот режим упрощает обработку GPO, помещая все настройки в политику TS OU Policy, но требует синхронизации с изменениями, вносимыми в политику "Users OU Policy". Например, если вы настроили прокси для IE с помощью групповых политик, то необходимо, чтобы значения, применяемые в объектах GPO, связанных с OU "Users", соответствовали значениям в объектах GPO, связанным с OU "Terminal Servers" (подразумевая, что настройки прокси одинаковы для сервера и рабочих станций). Если меняется адрес прокси-сервера, то вам следует изменить обе политики.

Разрешение обратного порядка

Обратный порядок разрешается в разделе Computer Configuration редактора Group Policy Object Editor (см. рисунок). Вы можете включить обратный порядок либо в локальной машинной политике на терминальном сервере, либо через любой объект GPO, примененный к терминальным серверам.

Результирующая политика

В сложных доменах со множеством групповых политик и комбинаций стандартной и обратной обработки довольно сложно отслеживать суммарный эффект объектов GPO и точно предсказывать результат перемещения пользователя или компьютера из одного OU в другой. Для помощи в этом Microsoft предлагает утилиту Resultant Set of Policy (RSOP.MSC).

Вы можете запустить ее с помощью команды Run для получения информации для текущего пользователя или компьютера, или из GPMC для тестирования сценариев регистрации пользователей на отдельных компьютерах. GPMC также предоставляет доступ к инструменту Group Policy Modeling, который вы можете использовать для тестирования "что будет, если..." перед внесением изменений в групповые политики или перемещением объектов.

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


Ссылка: http://www.oszone.net/172/