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

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

Разрешение	Описание
Query Information	Запрос информации через Terminal Services Administrator или с командной строки утилитой QUERY.
Set Information	Изменение настроек и разрешений RDP.
Remote Control	Просмотр или удаленное управление сеансом другого пользователя
Logon	Вход на сервер
Logoff	Принудительное завершение сеанса другого пользователя
Message	Отправка сообщений в другие сеансы на сервере используя консоль Terminal Services Manager или с командной строки командой MSG
Connect	Подключение к разъединенному сеансу того же пользователя
Disconnect	Принудительное отключение сеанса другого пользователя, оставляя сеанс на сервере в активном состоянии.
Virtual Channels	Использование виртуальных каналов - коммуникационных каналов, которые разработчики могут использовать для расширения возможностей RDP. Пока System имеет это разрешение, пользователи могут использовать приложения, использующие виртуальные каналы.

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

Permission	Guest Access	User Access	Full Control
Query Information		X	X
Set Information			X
Remote Control			X
Logon	X	X	X
Logoff			X
Message			X
Connect		X	X
Disconnect			X
Virtual Channels			X

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:///,user”

или

Set obUser = Get Object(“LDAP://”)

Как видно, для использования 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:windowsnotepad.exe” objUser.TerminalServicesWorkDirectory = “c:windows” objUser.TerminalServicesProfilePath = “\servertsprofilesjoe.user” objUser.TerminalServicesHomeDirectory = “\serverhomejoe.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 (http://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 и т.п.