суббота, 2 октября 2010 г.

Хранение учетных данных в скриптах и групповых политиках на примере задачи по смене пароля локального администратора

Введение

clip_image001С точки зрения безопасности пароль локального администратора должен соответствовать следующим требованиям:

· быть известным только ограниченному кругу лиц;

· обладать достаточной сложностью;

· регулярно изменяться.

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

1) при помощи стартап-скриптов;

2) используя предпочтения групповых политик;

3) запуском скрипта на выделенном компьютере.

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

Стартап-скрипты

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

Для решения применим скрипт, позаимствованный с блога «Hey, Scripting Guy!», и немного отредактируем его. В итоге получится что-то вроде:

strComputer = "."

Set objUser = GetObject("WinNT://" & strComputer & "/Administrator,user")

objUser.SetPassword "12345-as" '

objUser.SetInfo

Сам скрипт не идеален. Например, в него можно добавить:

1) привязку к SID встроенного администратора (это необходимо если учётная запись была переименована);

2) логирование в журнале событий системы;

3) отправку оповещений об ошибках выполнения по электронной почте.

Однако скрипт нужен нам лишь в качестве примера, поэтому нет смысла усложнять его структуру.

Теперь для автоматического изменения пароля администратора нам необходимо:

1) создать групповую политику;

2) добавить туда наш скрипт в качестве стартап-скрипта (более подробно об этом написано в KB198642);

3) прикрепить групповую политику к контейнеру с компьютерами, на которых должен изменяться пароль.

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

Кодирование

Для решения данной проблемы мы можем воспользоваться утилитой Script Encoder от компании Microsoft. Эта утилита позволяет преобразовать vbs-скрипт в формат vbe. В результате, тело скрипта хранится в закодированном виде и это никак не сказывается на возможности его исполнения. Рассмотрим это более подробно на нашем примере:

1) Скачиваем установочный файл с сайта Microsoft.

2) Распаковываем его.

3) В результате получаем несколько файлов. Один из них - нужная нам утилита screnc.exe. Синтаксис использования следующий:

SRCENC [switches] inputfile outputfile.

Здесь inputfile – исходный vbs-скрипт, outputfile – его зашифрованный аналог, [switches] – необязательные параметры, которые нам не понадобятся.

4) В итоге тело скрипта будет иметь вид:

«#@~^mQAAAA==dDD/K:aEYD,xPrRE@#@&?nO,W4Ni/DP{~!+Dr(LnmOcrrxgP)JzE~LP/O.;Whw!OD~LPrzb9:bUkkY.lDW.S!/+ME#@#@&W(%i/Dc?nYKCk/AWM[PrF+fW*OCdrPv@#@&G(Lik+MR?Y&U0K@#@&Ly4AAA==^#~@»

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

Декодирование

Казалось бы теперь учетные данные защищены и системный администратора может спать спокойно. Однако существуют vbs-скрипты, с помощью которых можно легко раскодировать зашифрованный вариант. Пример такого скрипта можно получить по следующему адресу: http://www.interclasse.com/scripts/decovbe.php.

Для его использования, скопируем код в файл decode.vbs и запустим его из командной строки. В качестве аргумента будет путь и имя закодированного vbe-файла:

decode.vbs output.vbe

В результате выполнения должно появиться окно, содержащее текст исходного vbs-скрипта. Как следствие учетные данные администратора опять могут стать известны потенциальному злоумышленнику.

Альтернативные варианты

Рассмотрим альтернативные способы решения задачи передачи учетных данных на рабочие станции. К таковым можно отнести:

1) Group Policy Preferences;

2) централизованное изменение пароля со стороны сервера;

3) усложнение структуры скрипта и ограничение доступа к нему.

Group Policy Preferences (GPP)

Предпочтения групповых политик это своего рода замена скриптам в групповых политиках. Данная технология активно рекламируется Microsoft и действительно значительно упрощает работу системного администратора. Изменение пароля локального администратора при помощи GPP довольно подробно описано в статье: «Change local administrator passwords with Group Policy Preferences». Ключевая мысль этой статьи: «Не рекомендуется изменять пароли локального администратора и сервисных учетных записей при помощи GPP». Связано это с тем, что ни смотря на то, что пароль администратора хранится в зашифрованном виде, для его получения достаточно 256bit AES ключа находящегося на рабочей станции. Таким образом, этот способ также не является безопасным.

Централизованное изменение пароля

Еще одним вариантом изменения пароля является выполнение скрипта не на рабочей станции, а непосредственно на сервере. Пример скрипта для осуществления этого можно найти в статье:

«How Can I Change a User’s Password?». Предложенный там скрипт:

Set objOU = GetObject("LDAP://OU=Finance, DC=fabrikam, DC=com")

objOU.Filter = Array("Computer")

For Each objItem in objOU

strComputer = objItem.CN

Set objUser = GetObject("WinNT://" & strComputer & "/Administrator")

objUser.SetPassword("i5A2sj*!")

Next

берет информацию о компьютерах из контейнера Active Directory и поочередно подключаясь к каждому из них меняет пароль администратора. Из минусов такого варианта можно отметить:

· необходимость удаленного подключения к компьютерам (а они не всегда могут быть доступны);

· организацию автоматического запуска скрипта по расписанию.

Усложнение структуры скрипта

Достаточно много вариантов с применением скриптов изложено в обсуждение «Смена пароля локального администратора» на форумах Microsoft Technet. Особенно интересен вариант с веб-сервером. При его использовании компьютер во время загрузке обращается к серверу, на котором выполняется скрипт по изменению пароля локального администратора. Таким образом этот способ удачно сочетает в себе двух других вариантов, основанных на использовании startup-скриптов и централизованной смены пароля.

Заключение

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

Ссылки:

· Script Encoder;

· Passwords in Group Policy Preferences;

· Change local administrator passwords with Group Policy Preferences;

· How Can I Change a User’s Password? ;

· Форумы Technet: Смена пароля локального администратора.

понедельник, 10 мая 2010 г.

Прозрачная авторизация на терминальных серверах

Введение

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

В связи с этим, для упрощения работы с удаленным рабочим столом в Windows Server 2008 появилась возможность использования технологии прозрачной авторизации Single Sign-on (SSO). Благодаря ей пользователь при входе на терминальный сервер может использовать учетные данные, введенные им при логине на свой локальный компьютер, с которого происходит запуск клиента удаленного рабочего стола.

В статье приведен обзор алгоритма работы технологии прозрачной авторизации Single Sign-On и поставщика услуг безопасности Credential Security Service Provider (CredSSP). Рассмотрен способ настройки клиентской и серверной частей. Также освещен ряд практических вопросов связанных с прозрачной авторизацией для служб удаленных рабочих столов.

Теоретическая информация

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

Впервые механизмы прозрачной авторизации появились в Windows Server 2008 и Windows Vista. благодаря новому поставщику услуг безопасности CredSSP. С его помощью кэшированные учетные данные передавались через безопасный канал (используя Transport Layer Security (TLS)). Впоследствии Microsoft выпустила соответствующие обновления для Windows XP SP3.

Рассмотрим это более подробно. CredSSP может использоваться в следующих сценариях:

· для сетевого уровня аутентификации (NLA), позволяя пользователю быть узнанным до полной установки соединения;

· для SSO, сохраняя учетные данные пользователя и передавая их на терминальный.

При восстановлении сеанса внутри фермы, CredSSP ускоряет процесс установки соединения, т.к. терминальный сервер определяет пользователя без установки полноценного соединения (по аналогии c NLA).

Процесс аутентификации происходит по следующему алгоритму.

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

2. Между сервером и клиентом устанавливается сессия. Для неё создается соответствующий ключ, который в дальнейшем будет участвовать в шифровании. CredSSP использует протокол Simple and Protected Negotiate (SPNEGO) для взаимной аутентификации сервера и клиента так, чтобы каждый из них мог доверять друг другу. Этот механизм позволяет клиенту и серверу выбрать механизм аутентификации (например, Kerberos или NTLM).

3. Для защиты от перехвата, клиент и сервер поочередно шифруют сертификат сервера, используя ключ сессии, и передают его друг другу.

4. Если результаты обмена и исходный сертификат совпадают, CredSSP на клиенте посылает учетные данные пользователя на сервер.

Таким образом, передача учетных данных происходит по зашифрованному каналу с защитой от перехвата.

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

1. Запустить редактор реестра regedit и перейти в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Добавить значение tspkg к ключу Security Packages (остальные значения этого ключа следует оставить неизменными).

3. Перейти в ветку реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders.

4. Добавить значение credssp.dll к ключу SecurityProviders (остальные значения этого ключа следует оставить неизменными).

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

Computer Configuration\Administrative Templates\System\Credentials Delegation.

В русскоязычных версиях операционных систем это выглядит следующим образом (рис. 1).

clip_image002

Рис. 1. Управление передачей учетных данных при помощи групповых политик

Для использования SSO следует включить политику:

Разрешить передачу учетных данных, установленных по умолчанию.

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

В окне редактирования политики (рис. 2) нажать кнопку «Показать»

clip_image004

Рис. 2. Окно редактирования групповой политики

Добавить список терминальных серверов (рис. 3).

clip_image006

Рис. 3. Добавление терминального сервера для прозрачной авторизации

Строка добавления сервера имеет следующий формат:

TERMSRV/имя_сервера.

Также можно задать сервера по маске домена. В этом случае строка приобретает вид:

TERMSRV/*.имя_домена.

Если нет возможности использовать групповые политики, соответствующие настройки можно установить при помощи редактора реестра. Например, для настройки Windows XP Sp3 можно использовать следующий файл реестра:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]

"Security Packages"=hex(7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\

00,6d,00,73,00,76,00,31,00,5f,00,30,00,00,00,73,00,63,00,68,00,61,00,6e,00,\

6e,00,65,00,6c,00,00,00,77,00,64,00,69,00,67,00,65,00,73,00,74,00,00,00,74,\

00,73,00,70,00,6b,00,67,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders]

"SecurityProviders"="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]

"AllowDefaultCredentials"=dword:00000001

"ConcatenateDefaults_AllowDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials]

"1"="termsrv/*.mydomain.com"

Здесь вместо mydomain.com следует подставить имя домена. В этом случае при подключении к терминальным серверам по полному доменному имени (например, termserver1.mydomain.com) будет использоваться прозрачная авторизация.

Для использования технологии Single Sign-On на терминальном сервере необходимо выполнить следующие действия.

1. Открыть консоль настройки служб терминалов (tsconfig.msc).

2. В разделе подключения перейти в свойства RDP-Tcp.

3. На вкладке «Общие» установить уровень безопасности «Согласование» или «SSL (TLS 1.0)» (рис. 4).

clip_image007

Рис. 4. Настройка уровня безопасности на терминальном сервере

На этом настройку клиентской и серверной части можно считать законченной.

Практическая информация

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

1. Технология Single Sign-On работает только при соединении с компьютеров под управлением операционной системы не Windows XP SP3 и более старших версий. В качестве терминального сервера могут быть использованы компьютеры с операционной системой Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2.

2. Если терминальный сервер, к которому устанавливается соединение, не может быть аутентифицирован через Kerberos или SSL-сертификат, SSO работать не будет. Это ограничение можно обойти с помощью политики:

Разрешить делегирование учетных данных, установленных по умолчанию с проверкой подлинности сервера «только NTLM».

3. Алгоритм включения и настройки данной групповой политики аналогичен представленному выше. Файл реестра, соответствующей данной настройке имеет следующий вид.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]

"AllowDefCredentialsWhenNTLMOnly"=dword:00000001

"ConcatenateDefaults_AllowDefNTLMOnly"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefCredentialsWhenNTLMOnly]

"1"="termsrv/*.mydomain.com"

Аутентификация данным способом менее безопасна, чем при использовании сертификатов или Kerberos.

4. Если для какого-либо сервера сохранены учетные данные в настройках терминального клиента, то они имеют более высокий приоритет, чем текущие учетные данные.

5. Single Sign-On работает только при использовании доменных аккаунтов.

6. Если подключение к терминальному серверу идет через TS Gateway, в некоторых случаях возможен приоритет настроек сервера TS Gateway над настройками SSO терминального клиента.

7. Если терминальный сервер настроен каждый раз запрашивать учетные данные пользователей, SSO работать не будет.

8. Технология прозрачной авторизации работает только с паролями. В случае использования смарт-карт, она работать не будет.

Для корректной работы SSO на Windows XP SP рекомендуется установить два исправления из KB953760: «When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server».

В некоторых случаях возможна ситуация когда на одном и том же терминальном клиенте технология прозрачной авторизации может работать или не работать в зависимости от профиля подключающегося пользователя. Проблема решается пересозданием профиля пользователя. Если это является слишком трудоемкой задачей можно попробовать воспользоваться советами из обсуждения: «RemoteApp Single Sign On (SSO) from a Windows 7 client» форумов Microsoft Technet. В частности, рекомендуется сбросить настройки Internet Explorer или одобрить соответствующую надстройку для него.

Еще одним серьезным ограничением технологии SSO является то, что она не работает при запуске опубликованных приложений через TS Web Access. При этом пользователь вынужден дважды вводить учетные данные: при входе на веб-интерфейс и при авторизации на терминальном сервере.

В Windows Server 2008 R2 ситуация изменилась в лучшую сторону. Более подробную информацию об этом можно получить в статье: «Introducing Web Single Sign-On for RemoteApp and Desktop Connections"».

Заключение

В статье рассмотрена технология прозрачной авторизации на терминальных серверах Single Sign-On. Её использование позволяет сократить время, затрачиваемое пользователем для входа на терминальный сервер и запуск удаленных приложений. Кроме того, с её помощью достаточно единожды вводить учетные данные при входе на локальный компьютер и затем использовать их при соединении с терминальными серверами домена. Механизм передачи учетных данных достаточно безопасен, а настройка серверной и клиентской части предельно проста.

Дополнительные ресурсы

· Single Sign-On for Terminal Services

· How to enable Single Sign-On for my Terminal Server connections

· Introducing Web Single Sign-On for RemoteApp and Desktop Connections

· Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3

· When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server

среда, 31 марта 2010 г.

Корпоративная активация Office 2010

Введение

Для корректного использования Microsoft Office 2010 необходимо своевременно активировать данный продукт. В статье рассматриваются механизмы корпоративной активации Microsoft Office 2010 такие как

· активация при помощи KMS-сервера;

· активация посредством ввода ключа MAK.

В зависимости от размеров организации рекомендуется выбрать один из этих способов.

Механизм активации аналогичен используемому при активации операционных систем таких как Windows Vista, Windows 7, Windows 2008 и Windows 2008 R2. Однако в отличии от операционных систем, в случае несвоевременной активации, программный продукт не потеряет своей функциональности. При этом пользователь будет получать предупреждения о необходимости активации в процессе эксплуатации.

Возможные механизмы активации

Для корпоративных пользователей существует два способа активации:

· активация посредством ввода ключа MAK;

· активация при помощи KMS-сервера.

Рассмотрим каждый из них более подробно

MAK

Этот способ активации наиболее подходит для организаций с небольшим числом компьютеров. При его использовании для активации требуется многократный ключ, состоящий из двадцати пяти символов. Данный ключ можно добавить в установочный пакет Microsoft Office 2010 через центр развертывания Office или файл config.xml. При каждой активации при помощи MAK число возможных активаций для организации уменьшается на единицу.

Также как и для случая операционных систем активацию можно проводить удаленно при помощи средства VAMT 2.0. В этом случае для клиентского компьютера необязательно соединение с интернетом (этот доступ должен присутствовать на сервере с установленным VAMT).

По умолчанию изменение ключа активации с KMS на MAK запрещено для пользователя. Для изменения этого поведения и предоставления пользователю возможности активировать данный продукт необходимо в раздел реестра

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform

добавить ключ UserOperations со значением 00000001 (тип ключа DWORD). Если значение данного ключа равняется нулю – изменение ключа и активация Office 2010 запрещена для обычных пользователей.

KMS

Данный способ активации используется по умолчанию. Для его использования требуется отдельный сервер, принимающий запросы на активацию. В качестве такового может быть использован сервер занимающийся лицензированием операционных систем. От пользователя не требуется никаких дополнительных действий для активации продукта. Сам сервер не требует постоянного доступа в интернет (он требуется лишь на момент активации). KMS-клиенту требуется периодическое соединение с севером активации (этот интервал может быть настроен). В случае недоступности сервера более 180 дней при запуске офиса появится предупреждение о том, что продукт не активирован. При этом функциональность его сохранится.

Также как и в случае с операционными системами существует порог активации. Для того чтобы сервер начал успешно активировать Office 2010 необходимо не менее 5 запросов от различных компьютеров.

Для управления KMS-сервером можно использовать скрипт slmgr.vbs. Более подробную информацию о синтаксисе и возможностях данного скрипта можно получить в статье «Краткое руководство по многопользовательской активации для Office 2010».

Заключение

В статье кратко рассмотрены преимущества и недостатки двух способов корпоративной активации Microsoft Office 2010.

Дополнительные ресурсы

Обзор многопользовательской активации Office 2010

Краткое руководство по многопользовательской активации для Office 2010

Полезные советы по многопользовательской активации Office 2010

Volume Activation for Microsoft Office 2010 (Beta)

понедельник, 15 марта 2010 г.

TS Easy Print на практике

TS Easy Print на практике

Введение

В качестве альтернативы использования традиционной системы печати в Windows 2008 появилась технология TS Easy Print, позволяющая избежать установки драйверов для перенаправленных принтеров на терминальном сервере. Благодаря этому значительно повышается стабильность работы как службы диспетчера очереди печати, так и всего терминального сервера в целом.

Внедрение TS Easy Print не требуется дополнительной установки серверной и клиентской части. Достаточно лишь наличие на рабочей станции клиента удаленного рабочего стола версии 6.1 (или старше) и .NET Framework 3.0 SP1 (или старше).

Статья разделена на два основных раздела.

Первая часть посвящена способам настройки и управления технологией TS Easy Print при помощи групповых политик и консоли управления печатью.

Во втором разделе собран практический опыт автора по использованию TS Easy Print, а также приведен ряд примеров из форумов Microsoft Technet.

Настройка

Для управления настройками печати на терминальном сервере в Windows Server 2008 существует несколько групповых политик. Найти их можно в следующем контейнере:

Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection.

В русскоязычном интерфейсе это

Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы терминалов\Сервер терминалов\Перенаправление принтеров (рис. 1).

image

Рис. 1. Групповые политики для управления перенаправленным принтерами

Рассмотрим каждую из них более подробно.

Таблица 1: Политики управления печатью на терминальных серверах

Групповая политика (в скобках представлен русский вариант названия)

Описание функциональности

Do not set default client printer to be default printer in a session (Не устанавливать используемый по умолчанию принтер клиента в качестве принтера для сеанса)

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

Do not allow client printer redirection (Не разрешать перенаправление клиентских принтеров)

Позволяет запретить подключение клиентских принтеров к терминальной сессии. Включение этой политики отключает перенаправление принтеров.

Specify terminal server fallback printer driver behavior (Задать поведение сервера терминалов при выборе резервного драйвера принтера)

Не смотря на существование этой политики использовать её можно только на Windows Server 2003.

Use Terminal Services Easy Print driver first (использовать в первую очередь драйвер принтера Easy Print служб терминалов)

Если эта политика включена или не настроена, сервер терминалов сначала попытается использовать драйвер принтера TS Easy Print для установки всех клиентских принтеров. Если по какой-либо причине драйвер TS Easy Print не доступен, используется драйвер принтера на терминальном сервере, соответствующий принтеру на клиентском компьютере. Если драйвер не найден на терминальном сервере, этот принтер не может быть перенаправлен.

Redirect only the default client printer (Перенаправлять только используемы по умолчанию принтер клиента)

Включает перенаправление только принтера по умолчанию. Остальные принтеры не перенаправляются.

Политики

Use Terminal Services Easy Print Driver First

и

Redirect Only The Default Client Printer

также можно найти в пользовательском разделе групповых политик в контейнере

User Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection.

Отдельно следует упомянуть о способах управления принтерами системными администраторами. По сравнению с Windows Server 2003, изменился механизм отображения доступных принтеров. Во время работы процесса Winlogon, диспетчер очереди печати перечисляет только принтеры, которые доступны пользователю в рамках его текущей сессии (вместо перечисления всех перенаправленных принтеров).

Однако, даже не смотря на то, что системный администратор не может видеть принтеры других пользователей, есть обходной маневр для получения информации о перенаправленных принтерах и выполнения с ними ряда административных задач. Члены группы «Print Operators» («Операторы печати») могут увидеть все перенаправленные принтеры в консоли управления печатью «Print Management Console» и панели управления принтерами. Для этого необходимо выполнить следующие действия.

1. Добавить себя в группу «Print Operators».

2. Установить роль «Print Services» на сервер.

3. Запустить консоль «Print Management».

По умолчанию администраторы и операторы печати не имеют прав на управление перенаправленными принтерами и могут только видеть их в консоли. Для управления перенаправленными принтерами необходимо предварительно захватить права владельца на него. Это делается следующим образом.

1. Открыть консоль управления печатью и щелкнуть правой клавишей мыши по выбранному принтеру.

2. Выбрать «Properties».

3. Перейти на закладку «Security».

4. Нажать «Advanced».

5. Перейти на закладку «Owner» (рис. 2).

image

Рис. 2. Захват прав владельца

6. Выбрать «Print Operators» и дважды нажать «Ок».

7. Закрыть все окна управления принтером.

8. Заново открыть окно свойств принтера.

9. Перейти на закладку «Security»

10. Добавить группе «Print Operators» право «Manage Printer».

image

Рис. 3. Добавление прав управления

Члены группы Print Operators должны использовать право Manage Printers только для выполнения следующих задач:

· удаление перенаправленного принтера;

· открытие очереди печати перенаправленных принтеров;

· управление заданиями на печать для перенаправленных принтеров.

Остальные действия, такие как переименование, установка для принтера свойств по умолчанию и предпочтений печати не поддерживаются.

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

Особенности практического использования

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

Проблема 1. Нестабильность службы диспетчера очереди печати

Основной предпосылкой внедрения TS Easy Print являются сбои в службе диспетчера очереди печати при использовании драйверов для принтеров на терминальном сервере. Эта проблема также актуальна и в «смешанной» среде. Если на терминальном сервере параллельно используются как TS Easy Print, так и традиционная система печати, проблемы могут только усугубиться. Это связано с тем, что при перезапуске службы диспетчера очереди печати, перенаправленные принтеры переходят в состояние offline и становятся недоступными для печати. Для наиболее быстрого решения этой проблемы требуется переподключение терминального сеанса. Всё это вызывает массу негативных отзывов (пример на форумах Microsoft Technet) со стороны конечных пользователей.

В качестве глобального решения этой проблемы можно рассмотреть полное удаление драйверов принтеров и сопутствующих им элементов с терминального сервера. Однако и эта операция может вызвать массу проблем (пример на форумах Microsoft Technet), так как вместе с драйверами принтеров могут удалиться драйвера Terminal Services Easy Print и Microsoft XPS Document Writer. Без них перенаправление принтеров по технологии TS Easy Print работать не будет.

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

· KB2000007;

· KB324757.

Перед их использованием настоятельно сделать резервное копирование системы.

Альтернативным способом является ручное удаление драйверов. Это делается следующим образом.

1. Перейти в «Панель Управления».

2. Выбрать «Принтеры»

3. Щелкнуть «Свойства Сервера» (рис. 4)

image

Рис. 4. Свойства сервера печати

4. Перейти на закладку «Драйверы» (рис .5)

image

Рис. 5. Драйверы принтеров

5. Поочередно удалить все драйверы кроме Terminal Services Easy Print и Microsoft XPS Document Writer.

Кроме того, можно дополнительно удалить данные из реестра и файловой системы. Более подробную информацию об этом можно получить в статье Print Spooler Crash Troubleshooting Steps.

Если терминальные сервера находятся терминальной ферме, и для соединения с ними используется ключ /admin, то при проверке нужно учитывать, что при таком типе подключения TS Easy Print не работает по умолчанию (KB947723).

Проблема 2. Печать «иероглифов» на перенаправленных принтерах»

При печати по технологии TS Easy Print могут отображаться «иероглифы». Обычно это вызывается старой версией .Net Framework. Установка более новой версии данного программного продукта может решить данную проблему. Данная проблема актуальна для старых версий клиентских операционных систем. Для Windows 7 дополнительная установка .Net Framework необязательна.

Проблема 3. Перенаправление принтеров не работает

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\fEnablePrintRDR.

Проблема 4. Пользователи не могут печатать на перенаправленных принтерах при совмещении ролей терминального сервера и контроллера домена

При совмещении ролей терминального сервера и контроллера домена у пользователей могут возникнуть проблемы с печатью (пример на форумах Microsoft Technet).

Для решения нужно дать права modify для группы everyone на папку: C:\Windows\System32\spool или воспользоваться статьей KB968605.

Проблема 5. Снижение скорости печати

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

Проблема 6. Не все принтеры перенаправляются в терминальную сессию

По умолчанию число перенаправляемых принтеров ограничено 20. Это поведение можно исправить добавив в раздел реестра

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

ключ MaxPrintersPerSession и задав в нем максимальное число перенаправляемых принтеров.

Проблема 7. Поддержка тонких клиентов

Одним из основных минусов технологии TS Easy Print являются требования к версии клиента удаленного рабочего стола и установке .Net Framework. Достаточно много тонких клиентов (особенно произведенных несколько лет назад) не имеют достаточно дискового пространства для использования операционной системы, содержащей данные программные продукты. Для остальных можно воспользоваться новой версией Windows Embedded 2009.

Заключение

В статье рассмотрена практическая сторона использования технологии TS Easy Print. Особое внимание уделено проблемам, которые могут возникнуть при переходе на новую систему печати. Не смотря на достаточно большое число перечисленных проблем, следует отметить, что технология TS Easy Print уже зарекомендовала себя с самой лучшей стороны и может быть использована в производственных целях. В качестве альтернативы TS Easy Print могут использоваться сторонние программные продукты (например, ThinPrint). Однако следует учитывать, что большинство таких продуктов платные и требуют установки дополнительного программного обеспечения.

Дополнительные ресурсы

· Windows Server 2008 Terminal Services Resource Kit

· Terminal Services Printing

· Terminal Server Easy Print

· WS2008: Terminal Services Printing

· Introducing Terminal Services Easy Print: Part 1

· WS2008: Terminal Services Architecture

· Using Remote Desktop Easy Print in Windows 7 and Windows Server 2008 R2

· Terminal Services Printer Redirection

· Printer Redirection

· Print Spooler Crash Troubleshooting Steps

Сравнение TS Easy Print и традиционной системы печати

Введение

В Windows Server 2008 появилась относительно новая технология печати на перенаправленных принтерах из терминальных сессий – TS Easy Print. С её помощью можно избавиться от необходимости установки и использования драйверов для принтеров на терминальных серверах. В результате этого значительно улучшается стабильность службы диспетчера очереди печати и как следствие удобство работы для конечных пользователей. В статье предлагается сравнительный обзор алгоритмов работы традиционной модели системы печати и технологии TS Easy Print. Представленная информация собрана из немногочисленных публичных источников, приведенных в конце статьи. В связи с этим, автор заранее просит прощения в случае неверной интерпретации доступной ему информации.

Традиционная модель системы печати

Вначале рассмотрим традиционную модель системы печати.

Основными компонентами, участвующими в перенаправлении принтеров и печати на них являются:

· winlogon.exe – процесс, отвечающий за создание и завершение сеанса, а также запуск оболочки пользователя;

· winsta.dll – библиотека, используемая для настройки терминальной сессии;

· termsrv.dll – диспетчер удаленных подключений;

· rdpwsx.dll – компонент, работающий в режиме пользователя и отвечающий за подключение/отключение удаленных соединений по протоколу RDP;

· rdpdr.sys – драйвер перенаправления RDP-устройств, работающий в режиме ядра;

· spoolsv.exe – диспетчер очереди печати на терминальном сервере;

· usbmon.dll – компонент управления динамическими портами принтеров на терминальном сервере;

· mstscax.dll – компонент терминального сервера, собирающий информацию о принтерах на клиентской рабочей станции (имя, драйвер, настройки и.т.п.);

· System Event Notification Service (SENS) – служба терминального сервера, отслеживающая такие системные события, как подключение\отключение сессий и создание\завершение сеансов на терминальном сервере, а также передающая информацию о них в приложения.

Автоматическое перенаправление принтеров клиента в терминальную сессию происходит по следующему алгоритму.

1) Пользователь при помощи клиента удаленного рабочего стола (mstsc.exe) подключается к терминальному серверу. В сессии пользователя создается процесс winlogon.exe. Компонент winsta.dll настраивает терминальную сессию.

2) Компонент rdpwsx.dll (при помощи winsta.dll и termsrv.dll) обнаруживает новое соединение и уведомляет об этом драйвер перенаправления устройств (rdpdr.sys).

3) Драйвер перенаправления устройств посылает запрос на составление списка принтеров для дальнейшего подключения их в сессию пользователя.

4) Клиент удаленного рабочего стола (mstsc.exe) собирает информацию с рабочей станции и через rdpwsx.dll посылает её драйверу перенаправления устройств. На терминальный сервер передаются следующие данные:

a) конфигурация принтера (имя принтера, имя драйвера, ориентация бумаги, статус и.т.п.);

b) имена очередей печати (очередь печати – это представление физического принтера в операционной системе Microsoft Windows) и соответствующих им портов;

c) очереди печати, находящиеся в разделе реестра HKCU\Software\Microsoft\Terminal Server Client\Default\Add Ins\RDPDR на клиентском компьютере (рис. 1).

clip_image002

Рис. 1. Пример реестра

5) Для каждой очереди печати при помощи драйвера перенаправления устройств создается соответствующий порт. Порты называются TSXXX, где XXX – номер, начинающийся с 001 (рис. 2). При этом учитываются заданные в групповых политиках настройки. Например, проверяется нужно ли перенаправлять все принтеры или только принтер по умолчанию.

clip_image003

Рис. 2. Порты перенаправленных принтеров

6) Драйвер перенаправления устройств через API уведомляет службу диспетчера очереди печати о появлении новых принтеров. Указанная служба с помощью Usbmon.dll добавляет созданные ранее порты в список доступных, а также производит соответствующие обновления в реестре клиентского компьютера.

7) Процесс winlogon.exe уведомляет службу SENS о создании терминальной сессии. С помощью этой службы удаляются созданные ранее порты при отключении и завершении сеанса.

8) Служба SENS выполняет следующие действия:

a) убеждается, что для принтера есть соответствующий драйвер на терминальном сервере;

b) устанавливает принтер по умолчанию на клиентской рабочей станции, принтером по умолчанию на терминальном сервере;

c) добавляет очередь печати в список устройств;

d) устанавливает права безопасности по умолчанию на очередь печати для подключившегося пользователя (чтение, запись, печать) и группы администраторов (полный доступ).

Процесс печати происходит по следующему алгоритму.

1. Пользователь запускает печать документа из какого-либо приложения.

2. При помощи интерфейса графического устройства (GDI), создается файл формата EMF (enhanced metafile format). Метафайл данного формата не зависит от устройства печати и содержит в себе инструкции необходимые для вывода изображения на принтер. Также, в зависимости от настроек принтера, файл может создаваться в RAW-формате (в этом случае GDI не используется).

3. Созданный файл передается в диспетчер печати на терминальном сервере. Он может быть сохранен на диск, если большое число заданий на печать становятся в очередь для одного принтера.

4. Постановленное в очередь задание возвращается в GDI. С помощью драйвера принтера, работающего в режиме пользователя, GDI преобразовывает задание на печать в RAW-формат, который может быть обработан выбранным принтером.

5. Задание на печать отправляется на перенаправленный порт (определенный как TSXXX).

6. Диспетчер печати посылает задание на печать на монитор динамического порта (Usbmon.dll).

7. Монитор динамического порта передает файл компоненту Rdpdr.sys, который посылает данные в готовом для печати растровом формате на соответствующий терминальный клиент и уже затем на нужный принтер.

Суммируя вышесказанное, следует отметить, что большая часть процесса обработки задания на печать происходит на терминальном сервере. Драйвер должен быть установлен на терминальном сервере (так как GDI форматирует данные в соответствии с выбранным принтером).

Архитектура TS Easy Print

Возможности печати на перенаправленных принтерах при подключении к удаленному рабочему столу существенно расширены благодаря универсальному драйверу печати TS Easy Print и Microsoft .NET Framework. С их помощью системные администраторы могут избежать следующих типовых проблем.

1. Критические сбои в работе терминального сервера из-за драйверов, работающих в режиме ядра.

2. Сопоставление имен драйверов. Иногда имена драйверов, установленных на рабочих станций, не совпадали с именами драйверов на терминальном сервере. Для работы перенаправленного принтера приходилось вручную делать сопоставление в соответствующем inf-файле.

3. Распространение драйверов. Необходимо было протестировать драйвер на одном из серверов и лишь затем распространять его на другие терминальные сервера.

4. Большой объем информации передаваемой по сети при печати на перенаправленный принтер из терминальной сессии.

Для решения указанных проблем, вместо традиционной системы печати предлагается использовать новую архитектуру, основанную на формате печати XML Paper Specification (XPS). С её помощью при печати на перенаправленном принтере можно использовать драйвера клиентского компьютера, не устанавливая их на терминальный сервер.

Для функционирования TS Easy Print на клиентском компьютере должны быть установлены клиент удаленного рабочего стола версии 6.1 или старше и .NET Framework 3.0 SP1 или последующих версий. Указанным требованиям удовлетворяют наиболее распространенные версии клиентских операционных систем, такие как Windows XP Sp3, Windows Vista, Windows 7. Следует отметить, что старая система печати также поддерживается и может использоваться параллельно с технологией TS Easy Print для работы с более старыми версиями терминальных клиентов.

Также как и традиционная система печати, TS Easy Print должна переводить данные в специальный формат и передавать их от терминального сервера к клиенту, на котором находится принтер. Основное отличие заключается в процессах преобразования и обработки заданий на печать.

При печати по технологии Easy Print создается XML файл, который в точности соответствует печатаемому документу. Основное отличие от формата EMF состоит в том, что данный файл может быть обработан XPS-совместимым драйвером без преобразования в RAW-формат. В связи с этим, большую часть времени файл, содержащий задание на печать гораздо меньше аналогичного EMF файла и как следствие требует меньше вычислительных ресурсов на обработку.

В основном, процесс обработки задания при использовании Easy Print сводится к получению заданию на печать и передаче его клиенту.

Печать происходит по следующему алгоритму.

1. Пользователь запускает задание на печать из какого-либо приложения в удаленной сессии.

2. В зависимости от типа приложения, задание на печать либо сразу же преобразуется в формат XPS (для приложений класса Windows Presentation Foundation), либо предварительно преобразуется в формат GDI (для Win32-приложений).

3. XPS-файл отправляется в надстройку клиента удаленного рабочего стола, отвечающую за технологию TS Easy Print.

4. XPS-файл без изменений передается напрямую драйверу печати на клиентском компьютере как XPS-обработанный файл.

5. XPS-файл, предназначенный для GDI принтера, превращается в формат EMF.

6. Задание на печать уходит на принтер.

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

Кроме того, TS Easy Print использует виртуальные каналы, предоставляя возможность настройки свойств печати непосредственно на клиенте. Когда пользователь входит в предпочтения печати в терминальной сессии, драйвер TS Easy Print на терминальном сервере перехватывает этот запрос и посылает его надстройке TS Easy Print на терминальном клиенте. Клиент опрашивает установленный локально драйвер и локальные настройки принтера. Таким образом, они полностью совпадают как на клиенте, так и на сервере. Дополнительным преимуществом TS Easy Print является то, что при передаче не добавляется информации связанной с драйвером печати.

Заключение

В статье рассмотрены две альтернативные технологии печати из терминальной сессии на перенаправленных принтерах. Благодаря своей архитектуре, TS Easy Print в большинстве случаев существенно превосходит традиционную систему печати по таким ключевым параметрам как

· стабильность службы диспетчера очереди печати;

· объем передаваемых при печати данных;

· необходимость установки драйверов для принтеров на терминальные сервера;

· скорость печати.

Однако и старая технология печати также имеет права на жизнь, т.к. не всегда удается выполнить условия функционирования TS Easy Print. Особенно это актуально для старых версий тонких терминальных клиентов.

Статья носит преимущественно теоретический характер. Особенности практического использования технологии TS Easy Print будут представлены в следующей статье.

Дополнительные ресурсы

· Windows Server 2008 Terminal Services Resource Kit

· Terminal Services Printing

· Процесс печати

· Printing

· Terminal Server Plug and Play Device Redirection Framework in Vista and Longhorn: Part 3

среда, 10 февраля 2010 г.

TS RemoteApp

Введение

Достаточно часто работа пользователя на терминальном сервере ограничивается запуском одного или нескольких приложений и не требует полноэкранной сессии. Технология Terminal Services RemoteApp (удаленные приложения) упрощает работу по такому сценарию. Удаленные приложения могут распространяться с помощью msi-пакетов и интегрироваться с локальной операционной системой. В частности, ярлыки этих приложений будут находиться в меню "Пуск" или на рабочем столе локального компьютера, а также использоваться при открытии ассоциированных с ними типов файлов.

Системные требования

Для использования технологии RemoteApp, клиент удаленного рабочего стола должен быть версии 6.0 или выше. В данный момент доступен клиент версии 7.0 для операционных систем: Windows XP, Windows Vista, Windows 2003/2008 Server. Установить его можно при помощи системы обновлений. В Windows 7 и Windows 2008 R2 он используется по умолчанию.

Принцип работы

В связи с необходимостью более полной интеграции с локальной системой, принцип работы удаленных приложений отличается от работы в полноэкранной сессии. Рассмотрим это более подробно (рис. 1). Информация позаимствована из Windows Server 2008 Terminal Services Resource Kit.

StartRemoteApp

Рис. 1. Схема запуска удаленного приложения

  1. Пользователь запускает клиент удаленного рабочего стола mstsc.exe и соединяется с сервером.
  2. Создается терминальная сессия. Открывается процесс Userinit.exe. Он стартует Rdpinit.exe, управляющий Rdpshell.exe. Rdpshell.exe - это оболочка, используемая при работе в удаленных приложениях вместо Windows Explorer (explorer.exe).
  3. Между клиентской и серверной составляющей устанавливается виртуальный канал. Он используется для передачи данных между сервером и клиентом.
  4. Rdpinit.exe проверяет список разрешенных для запуска приложений. Если приложение разрешено, терминальный сервер запускает его.
  5. Создается окно приложения.
  6. Rdpshell.exe взаимодействует с окном приложения и передает данные терминальному клиенту.
  7. Терминальный клиент создает окно, которое полностью идентично невидимому окну приложения на терминальном сервере. С этого момента пользователь может работать с приложением в обычном режиме.

За корректное отображение удаленных приложений отвечают следующие серверные компоненты:

  • Rdpinit.exe,
  • Rdpshell.exe,
  • Rdpdll.dll.

Rdpinit.exe - это аналог Userinit.exe. С его помощью запускаются логон-скрипты и создается оболочка пользователя. Rdpinit.exe отвечает за запуск Rdpshell.exe и обновление значков в панели уведомлений на стороне клиента через Rdpdd.dll. Кроме того, Rdpinit.exe управляет процессом завершения сеанса.

Rdpshell.exe на сервере отслеживает изменения, происходящие в окне приложения (например, открытие или закрытие) и передает их клиенту. Также, Rdpshell.exe обнаруживает соединение\отключение\переподключение терминальной сессии и соответственно закрывает или открывает окно приложения на стороне клиента.

Rdpdd.dll получает от Rdpinit.exe и Rdpshell.exe значки из панели уведомлений и обновляет их отображение на клиенте. Кроме того, Rdpdd.dll отслеживает изменения на стороне клиента и передает их приложению, запущенному на сервере.

Со стороны клиента, ключевой технологией при работе с удаленными приложениями является RemoteApps Integrated Locally (RAIL). Это расширение RDP-протокола, позволяющее более полную интеграцию с рабочим столом пользователя.

RAIL-клиент запускается на локальном компьютере пользователя и создает окно или значок оповещения для соответствующих им элементов приложения выполняемого на RAIL-сервере. Созданные окна\оповещения точно повторяют поведение окон\оповещений на терминальном сервере. Когда пользователь вводит какие-либо данные в Rail-окна\оповещения это захватывается RAIL-клиентом и передается на сервер. Аналогично данные передаются и в обратную сторону: все изменения отображения захватываются сервером и перенаправляются клиенту.

Более подробно взаимодействие между отдельными компонентами терминальных служб рассмотрено в статье WS2008: Terminal Services RemoteApps.

Установка и настройка
Пошаговую инструкцию по установке и настройке RemoteApp можно найти на сайте Microsoft Technet.

Здесь же остановимся на некоторых ключевых деталях настройки удаленных приложений.

При настройке удаленных приложений в консоли TS RemoteApp Manager можно выбрать разрешен или запрещен запуск неопубликованных приложений (рис. 2).

remoteapp1

Рис. 2. Параметры настройки развертывания удаленных приложений

Рассмотрим действие этой настройки на следующем примере.

На терминальном сервере опубликован исключительно Microsoft Word и пользователь при работе в нем открывает гиперссылку, содержащуюся в документе. В зависимости от указанной настройки, он сможет или нет запустить Internet Explorer в той же терминальной сессии.

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

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

При запуске удаленного приложения, вместо значка самого приложения отображается значок клиента удаленного рабочего стола. Для предоставления пользователю более полной информации о запускаемых приложений можно воспользоваться статьей How to make RemoteApp show the application icon when starting.

При установке службы удаленных приложений на странице "Метод проверки подлинности" следует указать, каким образом будет проверяться клиент перед подключением. Если все клиенты используют операционные системы, поддерживающие протокол CredSSP (например, Windows 7 или Windows Vista), рекомендуется установить требование проверки на уровне сети. В противном случае рекомендуется выбрать параметр "Не требовать проверку подлинности на уровне сети".

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

Удаленные приложения можно совмещать с технологией прозрачной авторизации Single Sign-On. В этом случае пользователю не нужно будет вводить пароль при первом запуске приложения.

Для простоты распространения удаленных приложений можно использовать TS WebAccess. Это позволяет публиковать подготовленные rdp-файлы на корпоративном веб-сайте.

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

Do not display Initial Configuration Tasks window automatically at logon,

Do not display Server Manager automatically at logon,

находящихся в разделе Computer Configuration\Administrative Templates\System\Server Manager.

В русской версии операционной системы данные политики (рис. 3) называются

  • Не отображать окно "Задачи начальной настройки" автоматически при входе,
  • Не отображать диспетчер сервера автоматически при входе.

remoteapp2

Рис. 3. Групповые политики, отвечающие за отображение Диспетчера Сервера и окна первоначальной настройки

Особенности использования

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

Сессия автоматически отключается когда все запущенные пользователем окна удаленных приложений и значки в панели уведомлений закрыты. Алгоритм принятия решения об отключении сессии приведен ниже (рис. 4).

TerminateRemoteApp

Рис. 4. Алгоритм отключения сессии

Сессия удаленного приложения остается активной до тех пока существует хотя бы одно видимое или активное окно в этой сессии. Активное окно может быть в любом состоянии (развернутое, свернутое, восстановленное). Кроме того, удаленное приложение, которому принадлежит окно, может быть запущено как непосредственно пользователем, так и в результате работы с уже запущенным приложением. Рассмотрим это на следующем примере.

Пользователь запускает удаленный Microsoft Outlook и открывает из него документ Microsoft Word, находившийся во вложении. Microsoft Word запускается в той же терминальной сессии отдельным удаленным приложением. Сессия будет оставаться активной до тех пор пока не закроются как Microsoft Outlook, так и Microsoft Word.

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

Пользователь запускает удаленный Microsoft Office Communicator. После открытия приложения в панели уведомлений появляется значок приложения. Он остается там даже если закрыть главное окно приложения. Соответственно, сессия также будет оставаться активной.

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

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

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

Сделать это можно с помощью политики «Set time limit for logoff of RemoteApp sessions», находящейся в разделе

Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Session Time Limits

В русскоязычных версиях операционной системы данная политика называется «Задать предел времени для выхода из сеансов RemoteApp» (рис. 5).

gp_ra

Рис. 5. Настройка ограничения по времени терминальных сессий

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

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

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

  1. Создать организационную единицу в оснастке Active Directory Users and Computers
  2. Переместить туда терминальный сервер
  3. Создать объект групповой политики и связать его с созданной ранее организационной единицей
  4. Создать группу безопасности. Включить в неё терминальный сервер и пользователей, которым запрещен доступ к полноэкранному рабочему столу
  5. В фильтрах безопасности объекта групповой политики удалить группу Authenticated users и добавить созданную ранее группу.
  6. В групповой политике установить следующие настройки:
  7. Computer Configuration\Policies\Administrative Templates\System\Group Policy\User Group Policy loopback processing mode - Enabled , mode - Merge
  8. User Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Start a program on connection - %systemroot%\system32\logoff.exe
  9. Обновить групповые политики командой: gpupdate /force

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

Дополнительные ресурсы

воскресенье, 24 января 2010 г.

TS Session Broker (Посредник служб терминалов)

Введение

Terminal Services Session Broker (посредник сеансов служб терминалов) - служба, позволяющая объединить несколько терминальных серверов в ферму. В предыдущей версии операционной системы подобной функциональностью обладала служба Terminal Server Session Directory. Она позволяла восстанавливать незавершенные сеансы при повторном соединении пользователя. В Windows Server 2008 эта служба была переименована, а также в ней добавился функционал по балансировке подключений. С помощью TS Session Broker можно обеспечить не только равномерную (по числу сессий) нагрузку на терминальные сервера, но и задать удельный вес сервера в ферме. Это позволяет направить большее число сессий на более производительные серверы.

Принцип работы

При подключении пользователя к ферме терминальных серверов следует разделять два этапа балансировки. На этапе первоначального подключения терминальные сессии распределяются на один или несколько серверов фермы. Это можно сделать встроенными средствами ДНС при использовании технологии round robin. В этом случае создается несколько записей с одним и тем же именем, ссылающихся на IP-адреса различных терминальных серверов. Также можно использовать NLB-кластер или аппаратную балансировку нагрузки.

После ввода пользователем учетных данных, наступает второй этап балансировки. Сервер авторизует пользователя и посылает запрос посреднику сеансов служб терминалов. Там определяется сервер для подключения. К нему перенаправляется пользовательская сессия.

При выборе сервера проверяется наличие у пользователя незавершенного сеанса. Если такой сеанс найден, терминальная сессия восстанавливается. Если у пользователя нет сеансов ни на одном из серверов фермы, он будет перенаправлен на сервер с наименьшим числом сессий. Сравнение числа сессий происходит с учетом удельного веса каждого сервера. Например, если в ферме находится два сервера с удельными весами 50 и 100, то на первый сервер будет перенаправляться в два раза меньше сессий чем на второй.

Файлы TS Session Broker находятся в каталоге: %systemroot%\system32\tssesdir. Информация о текущих соединениях хранится в базе данных tsesdir.edb. Для каждого сеанса определены:

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

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

Расположение базы данных tsesdir.edb можно изменить с помощью ключа реестра WorkingDirectory, находящегося в ветке: HKLM\System\CurrentControlSet\Services\Tssdis\Parameters.

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

  1. Посредник сеансов служб терминалов обнаруживает неудачное перенаправление сессии.
  2. Через некоторый интервал времени (по умолчанию минуту) он начинает пинговать "подозрительный" сервер.
  3. Если сервер остается не доступен (не отвечает на пинги) в течении заданного числа попыток, он удаляется из базы данных посредника сеансов служб терминалов.
  4. При перезапуске службы tssdis состояние базы данных восстанавливается.

Параметры этого процесса можно гибко настроить с помощью ключей реестра, находящихся в ветке: HKLM\System\CurrentControlSet\Services\Tssdis\Parameters. Рассмотрим их более подробно.

  • PingMode. По умолчанию равен 0. Рекомендуется не изменять этот параметр. Остальные значения используются исключительно в целях отладки.
  • TimeServerSilentBeforePing. По умолчанию равен 60. Определяет промежуток времени в секундах по истечении которого посредник сеансов служб терминалов начинает пинговать терминальный сервер после неудачной попытки подключения.
  • TimeBetweenPings. По умолчанию равен 10. Устанавливает число секунд между попытками пинга.
  • NumberFailedPingsBeforePurge. По умолчанию равен 3. Задает число попыток пропинговать сервер перед удалением из базы данных.
  • RecoverWhenStart. По умолчанию равен 1. Определяет необходимость восстановления базы данных при перезапуске службы tssdis.

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

Установка и настройка

Подробную инструкцию по установке и настройке посредника сеансов служб терминалов можно найти на сайте Microsoft Technet. Условно его можно разбить на три основных этапа.

  1. Установить роль терминального сервера со службой TS Session Broker.
  2. Добавить терминальные сервера в группу Session Directory Computers (локальная группа на сервере с установленным TS Session Broker).
  3. Настроить терминальные сервера на использование TS Session Broker.

Отдельно хотелось бы рассказать об особенностях балансировки посредником сеансов служб терминалов.

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

"Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера."

Подключение по имени сервера возможно лишь в случае если балансировка не потребует перенаправления. При подключении по IP-адресу сервера или по имени фермы сеанс будет распределен посредником сеансов служб терминалов. Единственный способ подключения, минуя балансировку - использование mstsc с ключом /admin. Этот метод аналогичен подключению к консоли на сервере Windows 2003 и требует наличия у пользователя административных прав.

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

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

Особенности практического использования

Этот раздел посвящен практическим нюансам использования TS Session Broker. Информация получена из практического опыта автора и обсуждений на форумах Technet.

При использовании посредника сеансов служб терминалов, от пользователей могут поступать жалобы на необходимость дважды вводить учетные данные при открытии сеанса. Примеры таких тем на форумах Technet:

http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/ed624e86-c692-481c-84eb-f9026b574dd9

http://social.technet.microsoft.com/Forums/en/winserverTS/thread/53cdb3ee-7c73-4cda-aff9-afffec4b94f3

Проблема связана с тем, что сервер, получив учетные данные пользователя при первоначальном соединении, перенаправляет его на другой терминальный сервер. При этом учетные данные не передаются и для входа на перенаправленный сервер пользователь вынужден вводить их второй раз. Для Windows XP с пакетом обновлений SP3 и более старших версий операционных систем это может быть решено с помощью Cred SSP. Данная технология позволяет программам передавать учетные данные пользователя с локального компьютера. Прочитать об этом можно в статье: KB951608

Более подробно это будет рассмотрено в одном из следующих материалов.

Иногда возникает ситуация когда посредник сеансов служб терминалов перестает направлять соединения на один или несколько серверов в ферме. Помогает перезапуск службы tssdis, но через некоторое время проблема возникает снова. Для устранения этого можно воспользоваться статьей KB955365.

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

Счетчик незавершившихся подключений возрастает на единицу в момент перенаправления сеанса с помощью посредника сеансов служб терминалов. Соответственно, после завершения подключения и открытия пользователем сеанса он уменьшается на единицу. Если счетчик одновременных подключений достигает 16, посредник сеансов служб терминалов прекращает направлять к нему сессии.

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

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

HKLM\SYSTEM\CurrentControlSet\Services\Tssdis\Parameters

Если такого ключа нет, его необходимо создать.

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

Для сохранения лога в файл необходимо добавить ключ TraceOutputMode со значением 3 в ветку HKLM\SYSTEM\CurrentControlSet\Services\Tssdis\Parameters

и перезапустить службу. Файл лога по умолчанию находится в каталоге: : %systemroot%\system32\tssesdir. Туда заносятся следующие события:

  • Запуск службы TS Broker;
  • Остановка службы;
  • Присоединение сервера к ферме;
  • Выход сервера из фермы;
  • Вход пользователя;
  • Отключение пользователя;
  • Восстановление сеанса;
  • Выход пользователя;
  • Сообщения системного журнала событий связанные с работой посредника сеансов служб терминалов.

В обычном режиме работы логирование лучше отключать. Для этого параметр TraceOutputMode надо установить равным 0.

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

Посредник сеансов служб терминалов необязательно устанавливать на терминальный сервер. Это может быть любой другой Windows 2008 сервер организации.

Контроль за корректным распределением терминальных сессий удобно осуществлять с помощью пакета управления терминальными серверами в System Center Operations Manager. График распределения сессий между терминальными серверами позволяет своевременно заметить сбои в балансировки и принять соответствующие меры для их устранения.

Дополнительные ресурсы