Версия для печати

Требования для доступа к терминальному серверу

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

Требования для доступа к терминальному серверу

WS2K3 имеет три различных уровня защиты, которые позволяют контролировать доступ к терминальному серверу. Чтобы пользователь мог зарегистрироваться на терминальном сервере, необходимо соблюдение следующих трех условий:

• Право Allow log on through Terminal Services (разрешен вход через службу терминалов) — В Windows 2000 вам необходимо было давать право Log on locally всем пользователям, которым требовался доступ терминальному серверу. Это создавало потенциальную брешь в безопасности, поскольку позволяло регистрироваться на консоли сервера, обходя ограничения, которые вы сделали для RDP. WS2K3 разделяет право локального входа и право входа через службу терминалов. По умолчанию, на WS2K3 право Allow log on through Terminal Services дается только администраторам и членам группы Remote Desktop Users.

• Права использовать RDP — Администратор может установить разрешения RDP с помощью Terminal Services Configuration. Как уже упоминалось, Microsoft изменила разрешения по умолчанию для протокола в WS2K3. Если в Win2K локальной группе Users был разрешен доступ к RDP, то в WS2K3 этот доступ ограничен только локальной группой Remote Desktop Users. Поэтому чтобы пользователи могли регистрироваться на терминальном сервере, вы должны поместить их в эту группу.

• Опция Allow logon to terminal (разрешен вход на терминальный сервер) — В свойствах каждого пользователя в AD есть опция Allow logon to terminal server, которая определяет, разрешено ли пользователю регистрироваться на терминальном сервере. По умолчанию эта опция включена.

Два из этих условий зависят от членства в группе Remote Desktop Users. Если пользователь получает сообщение You do not have permission to access this session, то одно из этих трех условий не соблюдается.

Allow Log On Through Terminal Services

Доступ к привилегии Allow log on through Terminal Services (разрешен вход через Terminal Services) осуществляется либо из Local Security Policy, либо из редактора групповых политик (GPEDIT.MSC ), в Security Settings, Local Policies, User Rights Assignment. После установки роли Terminal Services, эта привилегия дается локальной группе пользователей Remote Desktop Users.

Если терминальный сервер находится в домене AD, редактор Local Security Policy показывает как локальные настройки, так и эффективные, поскольку права могут назначаться доменными групповыми политиками. Если вы обнаружили, что эффективные права не дают достаточных привилегий нужным пользователям, вам следует использовать инструмент Resultant Set of Policy (RSOP.MSC) для определения того, какой объект GPO отзывает право.

Даже в WS2K3 право Log on locally открыто как администраторам, так и пользователям. Если терминальный сервер находится в незащищенной среде, вы можете ограничить это право только для администраторов, а пользователям разрешить доступ только через службу терминалов.

Разрешения для RDP

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

Как видно из рисунка, группа Remote Desktop Users по умолчанию разрешает доступ User Access. Каждый уровень доступа - гость, пользователь, полный контроль - идет с разным набором разрешений к сеансам на терминальном сервере. Чтобы полностью использовать мощь этих разрешений, вы должны понять, что предоставляет каждый из этих уровней доступа и какие доступны дополнительные опции.

Уровни доступа RDP

RDP предоставляет три основных уровня доступа: Guest Access (гость), User Access (пользователь) и Full Control (полный доступ). Уровень, назначенный группе, определяет возможности группы при подключении к терминальному серверу через RDP. Давайте разберемся с доступными разрешениями, а затем ассоциируем их с базовыми уровнями доступа. На следующем рисунке показан базовый список разрешений, а в таблице показано, как они относятся к пользователям.

В следующей таблице показано, какие разрешения назначены уровням доступа. Вы можете использовать редактор ACL для создания особых наборов разрешений. Например, вы можете дать сотрудникам справочного стола почти все разрешения Full Control, кроме Set Information.

Allow Logon to Terminal Server

Последнее требование для регистрации на терминальном сервере делается на уровне пользователей. В свойствах пользователей есть четыре вкладки, относящиеся к настройкам терминального сервера. Большинство из них затрагивают поведение сеанса при подключении пользователя к терминальному серверу. Вы можете использовать опцию Allow logon to terminal server чтобы целиком ограничивать способность пользователя подключаться к терминальному серверу. По умолчанию эта опция включена.

Настройка учетных записей пользователей

Пока мы рассматриваем интерфейс User Properties, я хотел бы обсудить остальные настройки терминального сервера. Большинство из этих настроек доступны в Terminal Services Configuration. Вы сами решаете, на каком уровне их применять - для отдельных пользователей или для сервера. Учтите, что настройки пользователя переопределяют настройки сервера. Для доступа к пользовательским настройкам используйте один из следующих инструментов: для доменов AD используйте инструмент Active Directory Users and Computers; для доменов NT 4.0 используйте User Manager for Domains, а для рабочих групп - Computer Management.

Вкладка Terminal Services, показанная в этом разделе, не видна в версии User Manager for Domains для NT 4.0; вы должны использовать версию этого инструмента для Win2K, WS2K3 или NT 4.0 Terminal Server Edition.

Независимо от используемого инструмента, вам доступны одни и те же опции. На следующем рисунке показаны вкладки Environment и Remote control.

Вкладка Environment используется для указания начальной программы и настроек переназначения ресурсов клиента. Если вы разрешите опцию Start the following program at logon setting, то при каждом подключении пользователя вместо рабочего стола будет запущена указанная программа.

В этом разделе настройки сервера переопределяют настройки пользователя. Так, если вы указали начальную прогорамму и в настройках пользователя, и в настройках сервера (с помощью Terminal Services Configuration), то будет запущена программа, указанная в настройках сервера.

На вкладке Remote control вы можете разрешить или запретить возможность удаленного управления сеансом этого пользователя. Если вы разрешаете удаленное управление, вы также можете указать требовать от пользователя разрешения, а также установить уровень управления. Эти настройки будут переопределены, если удаленный доступ сконфигурирован на сервере с помощью Terminal Services Configuration.

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

На вкладке Terminal Services Profile вы можете установить профиль и домашний каталог, используемый при регистрации пользователя на терминальном сервере. Здесь также находится опция Allow logon to terminal server, определяющая, может ли вообще пользователь регистрироваться на терминальном сервере. В отличие от других настроек в этом разделе, она не дублируется в Terminal Services Configuration.

Домашний каталог и каталог профиля

Будучи системным администратором, вы вероятно знакомы с сетевыми домашними каталогами и перемещаемыми профилями. Эти особенности Windows позволяют поддерживать центральное хранилище для пользовательских документов и настроек профиля, чтобы они были доступны независимо от компьютера, за которым сидит пользователь.

Terminal Services может поддерживать разные хранилища для домашних данных и профилей пользователей.

Путь к профилю Terminal Services

При регистрации пользователя на рабочей станции, система проверяет атрибут Profile Path объекта пользователя. Если пользователь имеет централизованно хранящийся профиль, и этот профиль новее, чем его локально кешированная копия, то профиль загружается для этого пользователя. Аналогично, когда пользователь регистрируется на терминальном сервере, система запрашивает атрибут UserParameters и ищет Terminal Services Profile Path.

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

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

Если вы не указали терминальный профиль, но указали перемещаемый профиль Windows, терминальный сервер будет использовать перемещаемый профиль Windows. Кроме того, если терминальный профиль указан, но недоступен, система вернется к профилю Windows. Это поведение может вызвать нежелательные результаты, если вы используете на сервере сценарии совместимости приложений.

Если вы используете перемещаемые профили Windows, использование профилей Terminal Services может стать еще более важным, поскольку если система не находит путь к терминальному профилю в учетной записи пользователя, она ищет путь к профилю Windows. В главе 5 вы познакомитесь со скриптами совместимости приложений, которые позволяют приложениям корректно работать на терминальном сервере. Эти скрипты вносят изменения в реестр в раздел HKEY_CURRENT_USER, чтобы помочь в настройке приложений для нескольких пользователей. Если эти изменения делаются в пользовательском профиле Windows, то пользователь может столкнуться с проблемами, когда в следующий раз зарегистрируется на рабочей станции.

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

WS2K3 имеет две новые политики, которые управляют пользовательскими профилями. Allow only local user profiles предотвращает указанному компьютеру загружать перемещаемые профили, даже если они сконфигурированы для пользователей. Set Path for TS Roaming Profiles позволяет указать специфический файловый сервер, который будет использоваться для перемещаемых профилей всех пользователей, регистрирующихся на терминальном сервере.

Домашние каталоги

Вы можете настроить учетные записи пользователей так, чтобы при регистрации на терминальном сервере они использовали другие домашние каталоги. Как вы увидите в главе 5, система использует пользовательский домашний каталог на драйве ROOTDRIVE и хранит там скрипты совместимости приложений. Отдельные домашние каталоги для терминалов позволяют держать файлы вне домашнего каталога Windows пользователя. Проблема состоит в том, что если ваш пользователь сохранил свои документы в домашнем каталоге Windows, то пользователю необходим доступ к тому же каталогу при регистрации на терминальном сервере. Если вы определили маршрут к домашнему каталогу Terminal Services, этот маршрут будет прменяться вместо домашнего каталога Windows. Если вы не указали домашний каталог Terminal Services, то будет использоваться домашний каталог Windows.

Настройка свойств пользователей через интерфейсы Active Directory Service

Использование графических утилит для конфигурации пользователей удобно, если у вас мало пользователей. Но если вам необходимо конфигурировать большое число пользователей, то легче это делать с использованием интерфейса службы активного каталога (Active Directory Service Interfaces, ADSI). По сравнению с Win2K эта особенность значительно улучшена.

Доступ к ADSI осуществляется через Windows Script Host (WSH), поэтому вы можете использовать скрипты на Visual Basic Script (VBScript) или Java Script. Примеры, приведенные далее, написаны на VBScript.

Конфигурирование пользователей через ADSI состоит из трех этапов. Сначала вы должны открыть соединение с учетной записью пользователя, затем установить свойства, и наконец записать изменения в учетную запись пользователя. Для открытия соединения вы используете либо провайдера WinNT, либо LDAP. Провайдер WinNT используется записями Security Accounts Manager (SAM) - либо локальными учетными записями на терминальном сервере, либо записями в домене NT 4.0. LDAP используется для учетных записей пользователей в АD.

Хотя вы можете использовать эти скрипты для конфигурирования как учетных записей домена NT 4.0, так и Win2K AD, вы можете запустить их только на сервере WS2K3; они не будут работать на Win2K и даже на Windows XP.

Синтаксис для соединения:

Set objUser = GetObject(“WinNT://<domain name>/<username>,user”

или

Set obUser = Get Object(“LDAP://<distinguished name of user>”)

Как видно, для использования LDAP вы должны знать отличительное имя объекта пользователя (например, cn=joe.user,ou=users,dc=example,dc=domain,dc=com), что нелегко, если ваши пользователи расположены в нескольких OU. Для облегчения этого Microsoft разрешила использовать провайдера WinNT также для учетных записей AD. Контроллер домена автоматически транслирует вызовы WinNT в вызовы LDAP.

Открыв учетную запись, вы устанавливаете параметры, которые хотите изменить. Имена параметров Terminal Services и синтаксис их использования приведены ниже:

objUser.ConnectClientDrivesAtLogon = [1,0]
objUser.ConnectClientPrintersAtLogon = [1,0]

ObjUser.DefaultToMainPrinter = [1,0]

objUser.TerminalServicesInitialProgram = [“path to program”]

objUser.TerminalServicesWorkDirectory = [“path to directory”]

objUser.TerminalServicesProfilePath = [“path to directory”]

objUser.TerminalServicesHomeDirectory = [“path to directory”]

objUser.TerminalServicesHomeDrive = [“drive letter:”]

objUser.AllowLogon = [1,0]

objUser.MaxDisconnectionTime = [minutes, 0 for never]

objUser.MaxConnectionTime = [minutes, 0 for never]

objUser.MaxIdleTime = [minutes, 0 for never]

objUser.BrokenConnectionAction = [1,0]

      1 = end session, 0 = disconnect the sesion

objUser.ReconnectionAction = [1.,0]

      1 = original client only, 0 = any client

objUser.EnableRemoteControl = [0,1,2,3,4]

0 = Disable Remote Control

1 = Enable Notify & Enable Interact

2 = Disable Notify & Enable Interact

3 = Enable Notify & Disable Interact

4 = Disable Notify & Disable Interact

Наконец, вы должны сохранить изменения в учетной записи пользователя:

objUser.SetInfo

Теперь объединим все это вместе и настроим параметры для одной учетной записи пользователя:

Set objUser = GetObject(“LDAP://cn=joe.user,ou=users,dc=example,dc=domain,dc=com”)

‘ илиr: Set objUser = GetObject(“WinNT://example/joe.user,user”)

objUser.ConnectClientDrivesAtLogon = 1

objUser.ConnectClientPrintersAtLogon = 1

objUser.DefaultToMainPrinter = 1

objUser.TerminalServicesInitialProgram = “C:\windows\notepad.exe”

objUser.TerminalServicesWorkDirectory = “c:\windows”

objUser.TerminalServicesProfilePath = “\\server\tsprofiles\joe.user”

objUser.TerminalServicesHomeDirectory = “\\server\home\joe.user”

objUser.TerminalServicesHomeDrive = “H:”

objUser.AllowLogon = 1

objUser.MaxDisconnectionTime = 15

objUser.MaxConnectionTime = 0

objUser.MaxIdleTime = 180

objUser.BrokenConnectionAction = 0

objUser.ReconnectionAction = 0

objUser.EnableRemoteControl = 1

objUser.SetInfo

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

Microsoft TechNet Script Center (https://www.microsoft.com/technet/scriptcenter ) - отличный ресурс для административных скриптов. Даже с небольшим знанием программирования вы можете изменить примеры скриптов, приспособив их для своих нужд.

Групповые политики

WS2K3 включает новый уровень гибкости при конфигурировании пользовательских сеансов - групповые политики. Как вы уже знаете, вы можете конфигурировать тайм-ауты сеансов, настройки ресурсов клиента, опции восстановления соединения для индивидуальных пользователей или отдельных серверов. С помощью групповых политик WS2K3 вы также можете управлять всеми этими опциями с помощью GPO.

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

Если вам необходимо установить опции в нескольких местах, или вы мигрируете из существующей терминальной инфраструктуры Win2K и уже сконфигурировали ваших пользователей и серверы, вы должны знать приоритет этих опций:

1. Настройки Computer Configuration Group Policy

2. Настройки User Configuration Group Policy

3. Настройки утилиты Terminal Services Configuration

4. Настройки пользовательской учетной записи

Будут побеждать настройки с более высоким приортитетом, поэтому настройки в Computer Configuration будут переопределять настройки User Configuration и т.п.

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

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

Active Directory Users and Computers

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

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

• Users - Контейнер по умолчанию для объектов пользователей, содержит встроенных пользователей, таких как Administrator и Guest, а также всех пользователей, которые находились в домене NT 4.0 при обновлении. Этот контейнер также содержит доменные глобальные группы, такие как Domain Admins и Domain Users.

• Computers - Контейнер по умолчанию для объектов типа компьютер, включает в себя все рабочие станции и серверы-члены, которые находились в домене NT 4.0 при обновлении.

• Domain Controllers - Контейнер по умолчанию для контроллеров доменов

• Builtin - Этот контейнер содержит встроенные доменные локальные группы, которые система использует для управления родными правами, как Server and Account Operators and Administrators.

• ForeignSecurityPrincipals - Этот контейнер используется системой для хранения ссылок на пользователей и компьютеры из других доверенных доменов.

Если вы управляете небольшим или средним доменом, этих контейнеров достаточно для удовлетворения ваших нужд. Однако, если вам необходимо организовать ваших пользователей, вы можете создать новые контейнеры 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 не инсталлируется. Вы можете загрузить ее отсюда: https://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:

• Do not display last user name in logon screen (Не выводить имя последнего пользователя на экране входа)

• Restrict CD-ROM access to locally logged-on user only (Ограничить доступ к CD-ROM только для локально вошедших пользователей)

• Restrict floppy access to locally logged-on user only (Ограничить доступ к FDD только для локально вошедших пользователей)

• Disable Windows Installer—Always (Запретить Windows Installer - Насовсем)

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

• Folder Redirection: Application Data

• Folder Redirection: Desktop

• Folder Redirection: My Documents

• Folder Redirection: Start Menu

• Remove Map Network Drive and Disconnect Network Drive (Удалить команды Map Network Drive и Disconnect Network Drive)

• Remove Search button from Windows Explorer (Удалить кнопку Search из Windows Explorer)

• Disable Windows Explorer’s default context menu (Запретить контекстное меню в Windows Explorer)

• Hide the Manage item on the Windows Explorer context menu (Спрятать команду Manage в контекстном меню Windows Explorer)

• Hide these specified drives in My Computer (enable this setting for A through D) (Спрятать следующие диски в My Computer - от A до D)

• Prevent access to drives from My Computer (enable this setting for A through D) (Запретить доступ к этим дискам в My Computer - от A до D)

• Hide Hardware Tab (Запретить вкладку Hardware)

• Prevent Task Run or End (Запретить запуск и завершение задач)

• Disable New Task Creation (Запретить создание новых задач)

• Disable and remove links to Windows Update (Запретить и удалить ссылки на Windows Update )

• Remove common program groups from Start Menu (Удалить группу общих программ из меню Start)

• Disable programs on Settings Menu (Запретить программы в меню Start)

• Remove Network and Dial-up Connections from Start Menu (Убрать пункт Network and Dial-up Connections из меню Start)

• Remove Search menu from Start Menu (Убрать пункт Search из меню Start)

• Remove Help menu from Start Menu (Убрать пункт Help из меню Start)

• Remove Run menu from Start Menu (Убрать пункт Run из меню Start)

• Add Logoff to Start Menu (Добавить понкт Logoff в меню Start)

• Disable and remove the Shut Down command (Запретить и удалить команду Shut Down )

• Disable changes to Taskbar and Start Menu Settings (Запретить изменения в панель задач и настройки меню Start)

• Hide My Network Places icon on desktop (Спрятать иконку My Network Places на рабочем столе)

• Prohibit user from changing My Documents path (Запретить пользователю менять путь My Documents)

• Disable Control Panel (Запретить Панель Управления)

• Disable the command prompt (Set Disable scripts to No) (Запретить командную строку)

• Disable registry editing tools (Запретить инструменты редактирования реестра)

• Disable Task Manager (Запретить Task Manager)

• Disable Lock Computer (Запретить Lock Computer)

Очевидно, что если вы используете все эти политики, то получите крайне строгую среду, почти не пригодную к использованию. Например, 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 не только показывает конечный эффект применения всех политик к пользователю или компьютеру, но также позволяет получить доступ к отдельным настройкам и увидеть все сконфигурированные политики.

Управление сеансами пользователей

Если у вас инфраструктура ориентирована на рабочие станции, то вы знаете, как трудно удаленно диагностировать и устранять проблемы ваших пользователей. Вероятно, вы используете такие средства, как Microsoft Systems Management Server (SMS) и Windows XP Remote Support для работы на пользовательском ПК и вы знаете, как удаленно подключиться к сетевому реестру для изменения настроек ваших пользователей.

В среде Terminal Services эти задачи упрощаются. Вместо того, чтобы разыскивать некоторую рабочую станцию на удаленном узле вашей сети, вы и ваши пользователи оба зарегистрированы на одном и том же компьютере. А поскольку вы оба используете RDP для передачи данных KVM, вы легко можете вмешаться. Чтобы показать разную технику поддержки, сначала познакомимся с утилитами поддержки.

Terminal Services Manager

При запуске утилиты Terminal Services Manger выводится список всех серверов, на которых установлены терминальные службы. С помощью этой утилиты вы можете легко видеть, к каким серверам подключены пользователи и с каких клиентских устройств, какие процессы и приложения работают в их сеансах.

Если вы знакомы с Win2K Terminal Services Manager, то заметите несколько улучшений в версии, включенной в состав WS2K3. Во-первых, новая версия содержит узел This computer, дающий быстрый доступ к сеансам сервера, на котором вы зарегистрированы. Во-вторых, есть узел Favorite Servers, который позволяет получить доступ к некоторым терминальным серверам, которые вы чаще всего администрируете. Наконец, узел All Listed Servers изначально не раскрыт, поэтому вам не нужно долго ждать поиска всех терминальных серверов перед началом использования этой утилиты.

Если вы выделите некоторый сервер, утилита покажет список всех пользовательских сеансов на этом сервере. Также показывается состояние каждого сеанса:

• Active (активный) — Пользователь в настоящий момент посылает на сервер информацию от клавиатуры или мыши

• Idle (холостой) — Пользователь не перемещал мышь и не нажимал клавиш в течении определенного промежутка времени

• Disconnected (разъединенный) — Пользователь отключился от сервера, но оставил сеанс работать для дальнейшего подключения.

Если вы в левой панели выберите сеанс пользователя, то в правой панели будет показан список всех процессов, выполняемых пользователем на сервере. В этой панели вы можете завершить зависший процесс.

Вкладка Information в правой панели сообщает имя устройства клиента и адрес IP, а также версию клиента RDP, разрешение экрана и уровень шифрования. Эта информация поможет в устранении проблем. Если вы щелкните правой кнопкой на пользовательском сеансе, появится контекстное меню:

• Connect — Прозволяет подключиться к другому сеансу, который вы установили на сервере

• Disconnect — Отключает пользователя от сеанса, но оставляет сеанс работать на сервере

• Remote Control — Позволяет просмотреть или взаимодействовать с сеансом пользователя, не отключая пользователя. Пользователь видит любые выполняемые вами действия, а вы в свою очередь можете наблюдать за действиями пользователя.

• Reset — Убить сеанс

• Status — Выводит окно состояния, показывающее сетевую активность между сервером и клиентом.

• Log Of f— Принудительное завершение сеанса

Опция Log Off аккуратно завершает сеанс и выгружает профиль пользователя в центральный каталог профиля. Однако она не оставляет пользователю возможности сохранить свою работу.

Удаленное управление

При выборе опции Remote Control вы временно отключаетесь от своего сеанса и подключаетесь к пользовательскому сеансу. Теперь RDP посылает всю видеоинформацию как на вашу машину, так и на клиентское устройство пользователя, и получает нажатия клавиш и перемещения мыши от вас обоих (если вы настроили интерактивное удаленное управление).

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

Редактирование реестра

Иногда необходимо отредактировать реестр пользователя. В случае с рабочими станциями, вам необходимо было подключаться к удаленному реестру пользовательского компьютера. На терминальном сервере вы совместно с вашими пользователями используете один и тот же реестр. Есть только один ключ HKEY_LOCAL_MACHINE для всех пользователей, а ключ HKEY_CURRENT_USER для каждого сеанса может быть найден в HKEY_USERS.

Каждый реестр пользователя имеет свой SID. Самый быстрый способ найти нужного пользователя, если вы не знаете его SID, заключается в просмотре подключа Volatile Environment для каждого пользователя. Этот подключ содержит переменную APPDATA, в которой содержится имя пользователя. Любые сделанные изменения становятся немедленно видимыми для пользователя.

Утилиты командной строки

Есть несколько утилит комадной строки, которые могут помочь в администрировании сервера. Большинство из них дублируют функции Terminal Services Manager, но версии командной строки удобны при написании скриптов.

• CHANGE USER {/Install /Execute} - Команда CHANGE USER используется для переключения сервера между режимами инсталляции и исполнения.

• CHANGE LOGON {/Enable /Disable} - запрещает прием новых соединений сервером

• Query {Process | Session | Termserver | User} - Команда Query дает ту же информацию, что и Terminal Services Manager; она перечисляет активные процессы в сеансе, доступные терминальные серверы и текущих пользователей.

• TSSHUTDN - TSSHUTDN используется для выключения или перезагрузки терминального сервера. Эта команда, в отличие от команды Shut Down в меню Start, предупреждает пользователей о выключении, чтобы они смогли сохранить свою работу. Затем осуществляется завершение каждого сеанса и в конце концов полное выключение сервера.

Вы можете сократить команду Query User до QUSER для быстрого получения списка активных сеансов на терминальном сервере. Есть также другие инструменты, которые могут помочь в управлении и блокировке терминального сервера, в управлении групповыми политиками, профилями пользователей и печатью. Например, triCerat Simplify Profiles позволяет сохранять, восстанавливать, создавать и удалять настройки реестра конечных пользователей.