Главная Security, Windows, Без рубрики, Новое Group Policy, Security
  • Хранение учетных данных в скриптах и групповых политиках на примере задачи по смене пароля локального администратора

    Введение

    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: Смена пароля локального администратора.

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

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

      В связи с этим, для упрощения работы с удаленным рабочим столом в 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_image004[5]

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

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

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

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

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

      clip_image006[7]

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

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

      clip_image008

      Рис. 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_image009

      Рис. 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

    • Главная Windows, Без рубрики, Новое Windows 2008 R2, Windows Server 2008
      • TS Easy Print на практике

        imageВ качестве альтернативы использования традиционной системы печати в 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

      • Главная Windows, Без рубрики, Новое EasyPrint, Windows 2008 R2, Windows Server 2008
        • Сравнение TS Easy Print и традиционной системы печати

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

        • Главная Windows, Без рубрики, Новое RemApp, Remote Desktop
          • TS RemoteApp

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

          • Главная Windows, Без рубрики, Новое Remote Desktop, Windows Server 2008
            • TS Session Broker

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