Настройка rds


Настройка стартового экрана RDS в Windows Server 2012

Как вы, вероятно, помните, в Windows 8 полностью отсутствует меню Пуск (Start Menu), функционал которого заменен новым плиточным интерфейсом под названием стартовый экран (Modern UI Start Screen). Этот факт касается и серверной платформы — Windows Server 2012. Это означает, что при входе терминального пользователя на сервер Windows 2012 с ролью   сервера терминалов  (RD Session Host) с установленной функцией «Desktop experience”, пользователю отображается не привычный рабочий стол сервера, а начальный экран Start Screen .

Соответственно, у администраторов терминальных служб появляются вопросы по настройке и управлению этим самым стартовым меню. В Windows Server 2008 R2 управление содержим меню Start осуществлялось (способ, рекомендуемый в best practice) путем перенаправления меню Start с помощью групповой политики в некую общую папку с ярлыками приложений, в которой отображение того или иного ярлыка определялось путем назначением на него NTFS прав и активного режима Access Based Enumeration. Что будет, если применить данную политику (User Configuration -> Windows Settings -> Folder Redirection -> Start Menu) к серверу с Windows 2012 RDS?

В Windows 2012 Remote Desktop при первом входе пользователя на «рабочий стол» терминального сервера он видит полностью пустой Start Screen:

Дело в том, что Start Screen просто не воспринимает политики перенаправления папки стартового меню (Start Menu),  которое использовалось в Windows Server 2008 R2. Ведь по новой концепции Microsoft это не одно и то же. Вместо этого данная политика перенаправляет меню All Apps в указанный в политике каталог.

Чтобы получить доступ к списку установленных программ, щелкните правой клавишей по начальному экрану (или нажмите комбинацию клавиш CTRL-TAB.

В меню All Apps отобразится список ярлыков  приложений, к которым у пользователя есть доступ (если на общем каталоге с ярлыками активна ABE и назначены NTFS права).

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

Таким образом, терминальный пользователь может настроить собственный начальный экран Metro UI (ака рабочий стол). Естественно, если данную операцию придется выполнять каждому пользователю сервера терминалов – это вызовет определённые проблемы и неудобства. Попробуем разобраться, можно ли экспортировать настройки стартового экрана у пользователя и групповой политикой назначить их всем остальным пользователям терминального сервера.

В Windows Server 2012 настройки стартового экрана хранятся в файле appsfolder.itemdata-ms, находящимся в каталоге %userprofile% \Default\appdata\local\microsoft\windows\appsfolder.itemdata-ms. Данный файл необходимо скопировать из профиля текущего пользователя и скопировать его в каталог C:\Users\Default\appdata\local\microsoft\windows\appsfolder.itemdata-ms. В этом случае все пользователи при первом входе на терминал получили бы новый профиль с настроенными ярлыками StartScreen.

Примечание.Есть небольшой нюанс, файл appsfolder.itemdata-ms – доступен только для чтения, и для того, чтобы пользователи могли редактировать свой стартовый экран, необходимо сменить его атрибуты. Проще всего это сделать с помощью политик Group Policy Preferences.

Согласитесь, получается не очень гибкая конфигурация. К счастью в релизе Windows Server 2012 R2 (и Windows 8.1) появится новая возможность экспорта конфигурации Start Screen.

Текущие настройки стартового экрана Start Screen пользователя можно выгрузить в XML файл с помощью команды Powershell export-startlayout

export-startlayout -as xml -path \\mskfs01\startscreen

В дальнейшем данный файл можно скопировать в общий каталог и распространить с помощью групповой политики Start Screen Layout, находящейся в разделе User Configuration  -> Policies  -> Administrative Templates -> Start Menu and Taskbar. В данной политике нужно задать путь к сохраненному xml файлу, задающему настройки Start screen.

Подробнее о возможностях и особенностях экспорта/импорта макета стартового экрана в статье: Управление конфигурацией плиточного стартового экрана в Windows 8.1

winitpro.ru

Установка и активация сервера лицензирования RDS на Windows Server 2016

В это статье мы рассмотрим процесс установки, настройки и активации роли сервера терминальных лицензий (Remote Desktop Licensing) на базе Windows Server 2016, а также процедуру установки и активации клиентских терминальных (CAL).

Напомню, что после установки роли терминального сервера Remote Desktop Session Host, пользователи могут использовать его только в течении пробного периода 120 дней, после окончания которого возможность подключения к удаленному RDS серверу пропадает. Согласно схеме лицензирования Microsoft, все пользователи или устройства, использующие возможности RDS, должны быть лицензированы. Для учета и выдачи терминальных лицензий (RDS CAL) существует отдельная служба роли RDS под названием Remote Desktop License Server.

Установка роли Remote Desktop Licensing

Переда началом установки нужно добавить (или убедиться, что у вас есть право на добавление) нового сервера в доменную группу Terminal Server License Servers, иначе сервер не сможет выдать CAL типа RDS Per User пользователям домена.

Установить службу Remote Desktop Licensing можно через консоль Server Manager. Для этого в мастере Add Roles and Features выберите роль Remote Desktop Services.

В качестве компонента роли нужно выбрать службу Remote Desktop Licensing.

Осталось дождаться окончания установки роли.

Активация сервера лицензий RDS

Чтобы сервер лицензирования RDS мог выдавать лицензии клиентам, его необходимо активировать. Для этого, откройте консоль Remote Desktop Licensing Manager, щелкните ПКМ по имени вашего сервера и выберите пункт меню Activate Server.

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

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

Осталось нажать кнопку Finish.

Теперь, если в консоли щелкнуть ПКМ по имени сервера и выбрать пункт Review Configuration, можно убедится что данный сервер сервер лицензий RDS является активированным и может быть использован для активации RDS клиентов в домене.

Типы клиентских терминальных лицензий (RDS CAL)

Каждый пользователь или устройство, которое подключается к серверам Remote Desktop Session должно иметь клиентскую лицензию (CAL — client access license). Есть два типа терминальных CAL.

  • На устройство (Per Device CAL) – это постоянный тип лицензии, назначающаяся компьютеру или устройству, которое подключается к RDS серверу более одного раза (при первом подключении устройства ему выдается временная лицензия). Данные лицензии не являются конкурентными, т.е. если у вас 10 лицензий Per Device, то к вашему RDS серверу смогут подключится всего 10 хостов.
  • На пользователя (Per User CAL) – такой тип лицензии позволяет одному пользователю подключаться к серверу RDS с любого количества компьютеров/устройств. Данный тип лицензий привязывается к пользователю Active Directory, но выдается не навсегда, а на определенный период времени (90 дней по-умолчанию).

Примечание. Отметим, что 2016 RDS CAL можно установить только на сервере лицензирования под управлением Windows Server 2016, установка новых CAL на предыдущие версии Windows Server на поддерживается.

Установка RDS CAL

Теперь на сервер лицензирования нужно установить приобретенный пакет терминальный лицензий (RDS CAL).

В консоли Remote Desktop Licensing Manager щелкните ПКМ по серверу и выберите Install Licenses.

Выберите способ активации (автоматически, через веб или по телефону) и программу лицензирования (в нашем случае Enterprise Agreement).

Следующие шаги мастера зависят от того, какой тип лицензирования выбран. В случае Enterprise Agreement нужно указать его номер. Если выбран тип лицензирования License Pack (Retail Purchase), нужно будет указать 25-символьный ключ продукта, полученный от Microsoft.

Тип продукта (Windows Server 2016), тип лицензии (RDS Per user CAL) и количество лицензий, которые нужно установить на сервере.

После этого, сервер может выдавать лицензии (RDS CAL) клиентам.

Настройка сервера лицензий на серверах RD Session Host

После, того как служба сервера лицензирования запущена и активирована, можно перенастроить терминальные сервера RD Session Host на получение лицензий с данного сервера. Выбрать тип лицензий и указать имя терминального сервера можно с помощью PowerShell или групповой политики.

Чтобы выбрать, какой тип лицензий использовать, выполните команду:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSettingЗатем укажите желаемый тип лицензирования

$obj.ChangeMode(4)

Примечание. 4 указывается, если сервер должен использовать тип лицензирования Per User, 2 – если Per Device.

Теперь можно указать имя сервера лицензирования RDS:

$obj.SetSpecifiedLicenseServerList("rds-lic1.winitpro.ru")

И проверить настройки:

$obj.GetSpecifiedLicenseServerList()

При настройке через GPO, нужно создать новую GPO и назначить ее на OU с RDS серверами. Настройки лицензирования задаются в разделе:

Computer Configuration -> Policies -> Admin Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing

В этом разделе имеется 2 интересующие нас политики:

  • Use the specified Remote Desktop license servers – задается адрес сервера лицензирования
  • Set the Remote Desktop licensing mode – выбор метода лицензирования

Проверить статус сервера лицензий и количество выданных лицензий можно с помощью консоли RD Licensing Diagnoser (Administrative Tools -> Remote Desktop Services -> RD Licensing Diagnoser).

Примечание. В нашем случае после указания нового сервера лицензирования, при подключении, на RDP клинте стала появляться ошибка «The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license». Решение – удаление ключа L$RTMTIMEBOMB из реестра.

winitpro.ru

Настройка терминальной фермы RDS с RD Connection Broker

Remote Desktop Connection Broker (RD Connection Broker), ранее известный под именем Terminal Services Session Broker (TS Session Broker), — это роль сервера Windows 2008 R2, предоставляющая следующий функционал:

  • Позволяет пользователям переподключаться к своим текущим сессиям в ферме серверов RD  Session Host (терминальные сервера Windows). Тем самым предотвращается создание новых пользовательских подключений на других серверах фермы при наличии подключения в состоянии «disconnected».
  • Позволяет равномерно распределить нагрузку между  серверами терминальной  фермы RD.

RD Connection Broker отслеживает все сессии пользователей в ферме терминальных серверов Windows Server 2008  R2. База данных RD Connection Broker хранит сессионную информацию, включая имена серверов RD Session Host, на которых  находятся сессии пользователя, идентификатор сессии (session ID) и имя пользователя, ассоциированное с сессией. Служба RD Connection Broker использует эту информацию для перенаправления пользователя, уже имеющего активную терминальную сессию на тот сервер, на котором она запущена.

В том случае, если пользователь отключился (disconnect) от своей сессии (из-за сетевого сбоя или осознанно), все приложения, которые он запустил на сервере продолжают работать. И когда пользователь пытается вновь подключиться к ферме терминалов, Connection Broker определяет сервер, на котором уже имеется сессия пользователя и перенаправляет подключение пользователя именно туда.

Балансировка нагрузки RD Connection Broker Load Balancing, позволяет при подключении пользователя (предполагается, что у него не осталось подключений в состоянии disconnect) к ферме, перенаправить его на наименее загруженный сервер фермы (с наименьшим количеством пользовательских сессий). Чтобы более гибко управлять балансировкой нагрузки в ферме терминальных серверов, администратор может в зависимости от вычислительных мощностей серверов фермы назначить каждому из них относительный вес.

Компоненты RD Connection Broker

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

Сервер RD Connection Broker. Это сервер с запущенной службой Remote Desktop Connection Broker, который отслеживает сессии пользователей и осуществляет балансировку нагрузки между членами фермы RD. Существует имя сервера RD Connection Broker, с помощью которого можно отнести конкретный терминальный сервер к той или иной ферме.

Сервера RD Session Host, настроенные на использование Connection Broker. Это рядовые члены  терминальной фермы.  Для того, чтобы являться членом фермы под управление RD Connection Broker, терминальный сервер должен соответствовать следующим критериям:

  • На сервере должна быть установлена роль RD Session Host.
  • Сервер должен быть членом домена Active Directory.
  • Сервер должен входить в локальную группу «Session Broker Computers» на сервере с ролью RD Connection Broker.

Последовательность настройки терминальной фермы RD Connection Broker с балансировкой нагрузки:

  1. Установите роль RD Connection Broker на сервере (это может быть выделенный сервер, или один из членов будущей фермы).
  2. Добавьте все терминальные сервера в локальную группу безопасности «Session Broker Computers» на сервере с ролью RD Connection Broker.
  3. Настройте всех членов фермы на использование сервера RD Connection Broker
  4. Настройте записи DNS  для реализация механизма «DNS round robin»

Шаг 1 : Установка роли Connection Broker

Если роль Remote Desktop Services уже установлена:

  • Разверните роль Remote Desktop Services.
  • Нажмите кнопку Add Role Services.
  • На странице служб роли выберите Remote Desktop Connection Broker и нажмите Next

В моем стенде 2 сервера, настроенных следующим образом:

RDS01

RDS02

Шаг 2 : Добавляем сервера RD Session Host в локальную группу Session Broker Computers.

Для этого на сервер с установленной ролью RD Connection Broker:

  • Нажмите Start -> Administrative Tools -> Computer Management.
  • В левой панели разверните узел Local Users and Groups, и выберите Groups.
  • Найдите локальную группу Session Broker Computers , и выберите пункт Properties.
  • На вкладке General, нажмите Add.
  • В окне выбора нажмите кнопку Object Types.
  • Отметьте пункт Computers, и нажмите OK.
  • Последовательно укажите и добавьте имена всех серверов, которые будут участвовать в терминальной ферме
  • Нажмите OK.

На  RDS01

Шаг 3 : Включаем сервера RD Session Host в ферму RD Connection Broker,  настраиваем балансировку нагрузки

На каждом из терминальных серверов RD Session Host выполните следующее:

  • На сервер RD Session Host откройте консоль Remote Desktop Session Host Configuration (Start ->Administrative Tools->Remote Desktop Services -> Remote Desktop Session Host Configuration).
  • В разделе Edit settings, щелкните по полю Member of farm in RD Connection Broker.
  • На вкладке RD Connection Broker нажмите кнопку Change Settings.
  • В окне RD Connection Broker Settings выберите Farm member.
  • Введите имя сервера с ролью RD Connection Broker.
  • В окне Farm name, укажите имя создаваемой фермы.
  • Чтобы активировать балансировку нагрузки в ферме RD Connection Broker  отметьте опцию Participate in Connection Broker Load-Balancing.
  • В случае необходимости можно настроить относительный вес каждого из серверов в ферме (Server weight). Значение по умолчанию — 100. В том случае, если вы зададите вес одного сервера 100, а другого 50, это будет означать, что сервер с меньшим весом будет получать в  2 раза меньше подключений.
  • По умолчанию используется перенаправление по IP адресу (IP address redirection), также можно использовать перенаправление по токену (Use token redirection).

Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02

Task 4 : Настройка DNS round robin

Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.

Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.

  • Откройте оснастку DNS (Start->Administrative Tools-> DNS).
  • Разверните сервер, и в зонах прямого просмотра  (Forward Lookup Zones), разверните ветку с именем вашего домена.
  • Щелкните по зоне и выберите New Host (A or AAAA).
  • В поле Name укажите имя фермы (именно фермы, а не конкретного сервера в ней), а в поле IP address укажите ip адрес первого сервера в ферме.

Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)

Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.winitpro.ru)

Теперь в дереве RD Connection Broker появится новая терминальная ферма!

winitpro.ru

RDS на основе сеансов в Windows Server 2012 R2. Часть 6 — Настройка роли шлюза подключений (RD Gateway) — bearded sysadmin

После выполнения процедуры установки роли шлюза удалённых рабочих столов на какой-либо сервер фермы RDS, его необходимо сконфигурировать. В подавляющем большинстве случаев, настроек, которые предлагает окно Свойства развёртывания, не достаточно. И вот тут, разработчики почему-то не стали интегрировать все необходимые настройки в единый интерфейс нового Диспетчера серверов, а оставили, как и в Windows Server 2008 R2, в отдельной оснастке — Диспетчер шлюза удалённых рабочих столов.

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

  1. Диспетчер шлюза удалённых рабочих столов
  2. Политики авторизации подключений к удалёному рабочему столу
  3. Политики авторизации ресурсов
  4. Настройка сервера шлюза
  5. Импорт и экспорт параметров политики и настроек

Диспетчер шлюза удалённых рабочих столов

Напомню, что с помощью консоли Службы удалённых рабочих столов можно настроить лишь самые базовые параметры шлюза RD Gateway. Для выполнения более гибкой настройки предлагается, как и в версии Windows Server 2008, пользоваться средствами Диспетчера шлюза удалённых рабочих столов. Добраться до него можно через Диспетчер серверов, зайдя в подпункт меню Terminal Services меню Средства. Так же можно воспользоваться разделом Администрирование или просто выполнить команду tsgateway.msc

Рис.1 — Запуск Диспетчера шлюза удалённых рабочих столов

На стартовом окне Диспетчера шлюза отображается самая основная статистика: количество подключений через шлюз, количество подключений именно к этому серверу, количество ресурсов, к которым созданы подключения, количество политик авторизации подключений и политик авторизации ресурсов, а так же общее количество серверов шлюзов в текущем развёртывании RDS.

Рис.2 — Главное окно Диспетчера шлюза

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

Рис.3 — Вкладка Наблюдение Диспетчера шлюза

Политики авторизации

Однако самыми важными опциями главного окна Диспетчера шлюза, безусловно, являются политики авторизации. Эти самые политики делятся 2 типа:

  • Политики авторизации подключений к удаленным рабочим столам (RD CAP), отвечающие за определение групп пользователей, которые наделены правом доступа к ресурсам RDS посредством шлюза удалённых рабочих столов.
  • Политики авторизации ресурсов удаленных рабочих столов (RD RAP), определяющие к каким ресурсам во внутренней сети дозволено иметь доступ пользователям подключившимся через шлюз удалённых рабочих столов.

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

Создание политики авторизации подключений (RD CAP) с помощью мастера

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

Рис.4 — Меню создания новой политики

На первом шаге мастера предлагается сделать выбор типа создаваемой политики: политика авторизации подключений, политика авторизации ресурсов или же обе политики сразу. Так как мы создаём политику авторизации подключений, то выбираем пункт Создать только политику авторизации подключений к удалённым рабочим столам.

Рис.5 — Выбор типа создаваемой политики

Далее задаём имя создаваемой политики.

Рис.6 — Указание имени новой политики

В окне Выбор требований можно выбрать способ проверки подлинности клиента, выполняющего подключение к шлюзу: с помощью пароля или с помощью смарт-карты. В поле Членство в группе пользователей (обязательно) следует указать те группы, пользователи которых смогут подключаться к удалённым рабочим столам используя при этом службу шлюза. Укажем здесь ранее созданную в AD группу Внешние пользователи. Кроме того, дополнительно можно задать и группу компьютеров, с которых может осуществляться подключение ранее определённой группой пользователей. Для этого достаточно указать группу компьютеров в поле Членство в группе клиентских компьютеров (необязательно). Таким образом можно определить не только пользователей, которые могут использовать шлюз, но и компьютеры с которых они могут это делать. Такой вариант, конечно же, добавляет жирный плюс к безопасности, но использовать его стоит с умом.

Рис.7 — Выбор групп пользователей и компьютеров

На вкладке Перенаправление устройств можно задать типы устройств, которые будут перенаправлены на серверы узлов сеансов. Присутствует возможность разрешить перенаправление всех клиентских устройств, запретить перенаправление определённых типов устройств или разрешить подключение только к тем серверам узлов сеансов удалённых рабочих столов, которые в принудительном порядке используют перенаправление устройств шлюзов удаленных рабочих столов. Однако же, использование последней опции возможно только для клиентов использующих для подключения RDC 7.0 и выше.

Рис.8 — Опции перенаправления устройств

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

Рис.9 — Настройка времени ожидания сеанса шлюзом

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

Рис.10 — Подтверждение выбранных настроек

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

Рис.11 — Политики авторизации подключений
Создание новой политики авторизации ресурсов (RD RAP) вручную

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

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

Рис.12 — Общие настройки политики авторизации ресурсов

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

Рис.13 — Настройка групп пользователей

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

Существует 3 варианта указания сетевых ресурсов:

  1. Выбрать группу сетевых ресурсов доменных служб Active Directory. Использование этого варианта подразумевает, что в Active Directory уже хранится необходимая группа ресурсов и можно просто указать её в этом поле.
  2. Выбрать существующую группу, управляемую шлюзом удалённых рабочих столов или создать новую. Использовав этот пункт администратор может создать группу сетевых ресурсов, перечислив их по IP-адресу или имени. Следует помнить, что эта группа видна только в Диспетчере шлюза и не является локальной для сервера (она не доступна в оснастке Локальные пользователи и группы).
  3. Разрешить подключение пользователей к любому сетевому ресурсу. Этот вариант подразумевает, что пользователи прошедшие авторизацию на сервере шлюзов будут иметь доступ к любому внутреннему ресурсу.
Рис.14 — Выбор сетевых ресурсов, которые должны быть доступны для пользователей

На вкладке Разрешённые порты можно указать по каким портам будут передаваться данные от шлюза к внутренним ресурсам. Как и на прошлой вкладке, выбор стоит между тремя вариантами:

  1. Разрешить подключения только к порту 3389. Этот вариант означает что, для подключения к ресурсам внутренней сети будет осуществляться только лишь по стандартному протоколу RDP.
  2. Разрешить подключения к следующим портам. В этом случае следует указать перечень портов, к которым разрешено подключаться. Это нужно в тех случаях, когда протокол RDP настроен на нестандартный порт (отличный от 3389) или есть необходимость в использовании дополнительных портов.
  3. Разрешать подключения к любому порту. Наименее безопасный вариант, так как, пользователь сможет использовать в своих целях абсолютно любой номер порта, что открывает перед ним довольно большие возможности.
Рис.15 — Настройка разрешенных для использования портов

Как и в случае с политикой авторизации подключений, после создания новой политики, отключаем политику созданную по-умолчанию.

Рис.16 — Политики авторизации ресурсов

Настройка шлюза удалённых рабочих столов

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

  • выбрать пункт главного меню Действие затем Свойства
  • зайти в контекстное меню конкретного сервера шлюза и выбрать пункт Свойства
  • на панели Действия выбрать пункт Свойства
Рис.17- Доступ к свойствам шлюза

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

  • Разрешить число одновременных подключений не более (…). Тем самым, можно задать конкретное число подключений.
  • Разрешить наибольшее число одновременных подключений. К серверу будет осуществленно максимально возможное количество подключений, после чего, он перестанет принимать новые подключения. Это максимальное число зависит от производительности аппаратной части сервера.
  • Запретить новые подключения. В этом случае все текущие подключения будут актив, но попытки установить новые, будут отклонены. Это значение целесообразно устанавливать в том случае, если сервер необходимо выключить, скажем, в профилактических целях.
Рис.18 — Настройка максимального количества подключений к серверу шлюза

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

Рис.19 — Управление сертификатами SSL

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

Рис.20 — Настройка протоколов HTTP и UDP

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

Рис.21 — Настройки, касающиеся фермы серверов

На вкладке Аудит, можно отметить, какие события следует журналировать. По-умолчанию выбраны все доступные события, но если в некоторых нет острой необходимости, их можно смело выключать. Это позволит немного разгрузить сервер и освободить место на дисковой подсистеме. Журнал службы шлюза удалённых рабочих столов можно посмотреть зайдя в средство Просмотр событий (Event Viewer). Далее следует перейти Журналы приложений и служб > Microsoft > Windows >TerminalServices-Gateway > Operational. В журнале Admin, который находится в этой же папке, можно отслеживать различные административные события, такие как, создание или удаление политик, изменение сертификата шлюза и прочие.

Рис.22 — Настройка событий для аудита

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

  1. Использование моста HTTPS-HTTPS. При такой конфигурации, клиенты которые выполняют подключение к шлюзу удалённых рабочих столов отправляют первоначальный SSL-запрос (HTTPS) мосту SSL. А затем, этот мост SSL отправляет новый HTTPS-запрос серверу шлюза. В этом случае обеспечивается максимальный уровень безопасности.
  2. Использование моста HTTPS-HTTP. При такой конфигурации клиенты, подключающиеся к шлюзу удалённых рабочих столов отправляют первоначальный SSL-запрос (HTTPS) мосту SSL. Далее мост SSL отправляет новый HTTP-запрос серверу шлюза.
Рис.23 — Параметры моста SSL

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

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

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

Рис.24 — Настройка сообщений

Такое вот окошко, будет отображено у пользователя, если администратор настроит системное сообщение.

Рис. 25 — Системное сообщение

А вот так выглядит сообщение, которое отображается при входе.

Рис.26 — Сообщение при входе в систему

 

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

Вкладка Хранилище политики авторизации подключений к удалённым рабочим столам позволяет задать место хранения политик авторизации подключений (RD CAP): на локальном сервере или на централизованном сервере политики сети (NPS). Если в сети такой сервер присутствует, то, безусловно, следует его использовать. Для этого необходимо выбрать соответствующий пункт и ввести IP-адрес или имя сервера NPS.

Рис.27 — Указание места хранения политик авторизации подключений

Для того, чтобы клиенты отправляли информацию о своем состоянии следует установить галочку Запросить отправку клиентами состояния работоспособности. В целом, это одна из функций NAP (Network Access Protection), которая позволяет отслеживать состояние ключевых для безопасности служб на компьютере клиента.

Импорт и экспорт параметров сервера шлюза удалённых рабочих столов

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

Сделать это можно с помощью контекстного меню сервера. В нём присутствуют пункты Экспорт параметров политики и конфигурации и Импорт параметров политики и конфигурации.

Рис.28 — Средства экспорта и импорта политики и конфигурации шлюза

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

Рис.29 — Параметры экспорта политики и конфигурации шлюза

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

Рис.30 — Параметры импорта политики и настроек

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

Рис.31 — Уведомление о необходимости выполнения дополнительной проверки настроек

***

Как мы видим, Диспетчер шлюза удалённых рабочих столов позволяет достаточно тонко настроить параметры доступа к службам RDS и внутренним ресурсам для клиентов, находящихся вне корпоративной сети. В итоге выполнения настройки политик авторизации подключений и авторизации ресурсов, можно достаточно точно задать кто может подключаться, с каких компьютеров и к каким конкретно ресурсам внутренней сети. А с помощью окна свойств можно регулировать множество настроек, среди которых порты транспортных протоколов, максимальное количество подключений к серверу шлюза, служебные сообщения, мост SSL и прочие. Конечно, в некоторых случаях можно обойтись и средствами, которые находятся в окне Службы удалённых рабочих столов Диспетчера серверов, но использование Диспетчера шлюза позволяет значительно снизить возможность несанкционированного доступа снаружи с помощью средств шлюза удалённых рабочих столов.

beardedsysadmin.wordpress.com

Remote Desktop Services - Настраиваем пользовательский интерфейс на серверах RD Session Host

Серверы сеансов Remote Desktop Services (RDS) - это многопользовательские среды, для которых, как правило, требуется максимально жёсткая настройка пользовательского окружения. Говоря простым языком, – чем у пользователей меньше отвлекающих "буцок", не имеющих прямого отношения к выполняемым ими задачам, – тем лучше и для администратора, и для них самих в конечном итоге. Здесь мы рассмотрим пример настройки некоторых элементов пользовательского интерфейса по следующим позициям:- Отключаем отображение Favorites, Libraries и Network- Скрываем излишние папки в профиле пользователя- Отключаем мастер добавления сетевых расположений- Скрываем локальные диски сервера- Сворачиваем ленту при запуске Windows Explorer- Включаем отображение расширений файлов- Ограничиваем набор апплетов в Панели управления- Настраиваем панель задач (TaskBar)- Заменяем картинку пользователя по умолчанию- Настраиваем стартовый экран Windows- Создаём групповую политику переопределений для администраторов

Отключаем отображение Favorites, Libraries и Network

Для того чтобы скрыть элементы Favorites, Libraries и Network из панели навигации Windows Explorer нужно изменить значения соответствующих трёх параметров системного реестра.

Отключить отображение Favorites:HKEY_CLASSES_ROOT\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolderПоменять значение параметра Attributes с a0900100 на a9400100

Отключить отображение Libraries:HKEY_CLASSES_ROOT\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}\ShellFolderПоменять значение параметра Attributes с b080010d на b090010d

Отключить отображение Network:HKEY_CLASSES_ROOT\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolderПоменять значение параметра Attributes с b0040064 на b0940064

Выполнить изменения этих параметров можно например с помощью Group Policy Preferences (GPP), создав в групповой политике применяемой к серверам RDS соответствующие настройки GPP в разделе Computer Configuration\Preferences\Windows Settings\Registry

При желании можно для применения данного ключа реестра настроить Item-level targeting (ITL) на семейство ОС – Windows Server 2012 Family. Проблема с применением перечисленных параметров реестра заключается в лишь том, что по умолчанию к родительским ключам этих параметров для пользователя SYSTEM предоставлен доступ только на чтение, и без добавления права на редактирование наши параметры GPP применены не будут.

Учитывая то, что владельцем этих ключей является SYSTEM, нам потребуется от имени этого пользователя запустить редактор реестра и добавить права на редактирование. Запустить редактор реестра от имени системы (SYSTEM) можно, например, с помощью утилиты PsExec.exe из состава Sysinternals PsTools командой

PsExec.exe /i /s regedit

 

Скрываем излишние папки в профиле пользователя

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

- Изменить атрибуты папок (или удалить эти папки вообще) в профиле по умолчанию который используется системой при создании новых профилей C:\Users\Default\

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

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

***

А) Вариант с использованием логон-скрипта обрабатываемого системой при входе пользователя, в котором для всех нужных папок добавлены конструкции типа:

attrib +r +s +h "%USERNAME%\Saved Games" /S /D

Такая конструкция добавит атрибуты “Скрытый” и “Системный” к указанной папке. Добавление атрибута “Системный” позволит нам спрятать указанные папки действительно во всех диалоговых окнах Windows Explorer, чего нельзя добиться при использовании только атрибута “Скрытый”.

Информацию о том, как при необходимости добавить собственный логон-скрипт на сервер RDS можно найти в заметке Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup

***

Б) Вариант удаления нежелательных папок в уже существующих профилях. Можно воспользоваться логон-скриптами в случае если нужна сложная логика проверки наличия в этих папках какого-либо пользовательского контента. Если же точно известно, что в профилях пользователей в этих папках ничего нет, то можно использовать для жёсткого удаления этих папок механизмы GPP в разделеUser Configuration\Preferences\Windows Settings\Folders

При создании настройки GPP для операции удаления файлов/папок в пользовательском профиле обязательно включать параметр выполнения задачи в контексте пользователя – Run in logged-on user’s security context (user policy option) на закладке Common

Для удаляемых GPP папок также нужно не забыть отключить для этих папок механизм их перенаправления (Folder Redirection), в противном случае при каждом входе пользователя в систему будет идти противоборство механизмов перенаправления папок и удаления этих же папок через GPP, то есть сначала папки будут создаваться а потом тут же удаляться.

***

B) Третий вариант, самый приемлемый на мой взгляд. Параллельно использованию механизма перенаправления папок с помощью GPP запускать скрипт установки атрибутов “Скрытый” и “Системный” для нужных папок пользователя, то есть и папки останутся целыми и от пользователя мы их скроем. Для этого создадим параметр GPP в разделе User Configuration\Preferences\Windows Settings\Registry - строковой параметр реестра REG_SZ с любым именем, например HideUserProfileFolders в ключе HKCU\Software\Microsoft\Windows\CurrentVersion\Run и значением \\FileServer\RDS_UserSettings\Hide-User-Profile-Folders.vbs

Таким образом мы пропишем в автозагрузку пользовательской среды запуск скрипта, расположенного на общедоступном сетевом ресурсе. В теле скрипта будем выполнять проверку на наличие атрибутов “Скрытый” и “Системный” на нужных нам папках и если атрибут не установлен – будем его устанавливать. Пример такого скрипта:

Set WS = CreateObject("WScript.Shell") Set FS = CreateObject("Scripting.FileSystemObject") vRootFolder = WS.ExpandEnvironmentStrings("%RDS_RFOLDERS%") vUserName = WS.ExpandEnvironmentStrings("%USERNAME%") arrSubFolders = Array("Contacts", "Downloads", "Favorites", "Links","Music", "Saved Games", "Searches", "Videos" ) For i = LBound(arrSubFolders) to UBound(arrSubFolders) vPath = vRootFolder + "\" + vUserName + "\" + arrSubFolders(i) If FS.FolderExists(vPath) Then Set objFolder = FS.GetFolder(vPath) If ((objFolder.Attributes AND 2) = 0) Then 'Folder Not Hidden objFolder.Attributes = objFolder.Attributes + 2 End If If ((objFolder.Attributes AND 4) = 0) Then 'Folder Not System objFolder.Attributes = objFolder.Attributes + 4 End If End If Next

Дополнительно найти примеры манипуляций с каталогами из VBS можно найти по ссылке ActiveXperts.com - Scripts to manage Folders.

Обратите внимание на то, что в теле скрипта используется переменная окружения %RDS_RFOLDERS%. Так как речь идёт о том, что папки пользователя над атрибутами которых мы собираемся провести изменения, являются перенаправленными (Folder Redirection), то к ним нельзя обратиться просто используя переменную %USERPROFILE%. Вместо этого нужно указать путь к фактическому размещению сетевого каталога для перенаправляемых папок пользователя, и для того чтобы указать этот каталог можно использовать дополнительную переменную в теле самого скрипта, а можно опять-же с помощью GPP создать пользовательскую переменную окружения куда и записать это значение. После этого созданную переменную можно будет использовать как в этом, так и в других скриптах настройки пользовательской среды. Итак, для создания дополнительной пользовательской переменной, создадим параметр GPP в разделе User Configuration\Preferences\Windows Settings\Environment

После применения созданных нами параметров GPP и отработки скрипта при входе пользователя в уже созданный профиль (то есть это не применимо для первого входа в систему с созданием нового профиля), мы получим следующий результат:

 

Отключаем мастер добавления сетевых расположений

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

Для этого достаточно настроить предопределённый параметр GPO Remove "Map Network Drive" and "Disconnect Network Drive"в разделах User Configuration\Policies\Administrative Templates\Windows Components\File ExplorerComputer Configuration\Policies\Administrative Templates\Windows Components\File Explorer

 

Скрываем локальные диски сервера

Для того чтобы скрыть от пользователей все локальные диски сервера, оставив возможность видеть в Windows Explorer лишь свои перенаправленные диски включим и настроим параметр GPO Hide these specified drives in My Computer  =  Restrict all drivesв разделеUser Configuration\Policies\Administrative Templates\Windows Components\File Explorer

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

 

Сворачиваем ленту при запуске Windows Explorer

Ещё один предопределённый параметр GPO позволит нам настроить запуск новых окон Windows Explorer со свёрнутой лентой (верхней панелью кнопок).Start File Explorer with ribbon minimized установим в значение Always open new File Explorer windows with the ribbon minimizedв разделах User Configuration\Policies\Administrative Templates\Windows Components\File ExplorerComputer Configuration\Policies\Administrative Templates\Windows Components\File Explorer

Несмотря на то что этот же параметр GPO есть в User Configuration, он по какой-то причине подавляется существующим параметром реестра ExplorerRibbonStartsMinimized в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorerи это происходит даже не смотря на то, что данная политика в Computer Configuration не настроена. Такое поведение лечится лишь явным отключением этой политики в Computer Configuration, и поэтому особого смысла в этой политике на уровне User Configuration я не вижу и использую её на уровне Computer Configuration

 

Включаем отображение расширений файлов

Отключаем включенную по умолчанию опцию сокрытия расширений для зарегистрированных типов файлов (Hide extension for known file types).

Для этого создадим параметр GPP в разделе User Configuration\Preferences\Windows Settings\Registry - параметр реестра REG_DWORD с именем HideFileExt и значением 0 в ключе HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advancedс типом действия Update

 

Ограничиваем набор апплетов в Панели управления

В панели управления скроем все апплеты кроме тех, которые реально могут понадобиться пользователям с помощью предопределённого параметра GPOShow only specified Control Panel items в разделеUser Configuration\Policies\Administrative Templates\Control PanelВ таблице настройки отображаемых значений на всякий случай введём русский и английский вариант имён апплетов Панели управления:

Свойства браузераЯзыкРегиональные стандартыУстройства и принтерыInternet OptionsLanguageRegionDevices and Printers

Дополнительно через GPP задаем вид элементов Control Panel в виде маленьких значков через Update двух параметров реестра в ключе: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ControlPanelAllItemsIconView REG_DWORD = 1StartupPage REG_DWORD = 1

В результате применения созданных параметров GPO в пользовательском окружении получим следующий вид Панели управления:

 

 

Настраиваем панель задач (TaskBar)

Общая методика следующая – сначала настраиваем в текущем профиле пользователя панель задач так, как она должна выглядеть у всех других пользователей, после этого, с помощью механизмов GPP, передаём параметры реестра, отвечающие за хранение настроек TaskBar из текущего профиля в другие.

Итак, сначала мы должны “запилить” TaskBar в текущем профиле до желаемого вида.

Создаём на рабочем столе ярлыки, ссылающиеся на исполняемые файлы. При желании меняем иконки для ярлыков, добавляем в свойства ярлыка Комментарий который будут видеть пользователи при наведении курсора на этот ярлык и т.д. Если необходимо сделать ярлык на какой либо каталог (локальный или сетевой), то ярлык делаем для исполняемого файла C:\Windows\explorer.exe и через пробел добавляем имя каталога который должен открываться этим ярлыком.

Если есть сильное желание создать на панели задач отдельную кнопку свёртывания/развертывания всех окон (не все пользователи знают о самой правой узкой кнопке на панели задач в W8/W2012, которая отвечает за свёртывание/развертывание), то можно использовать следующий шаманский метод..

1. Создаём пустой файл с каким-нибудь диким именем, например nullprogram.exe 2. Делаем ярлык на этот файл, устанавливаем ярлыку имя которое мы хотим получить в результате например "Свернуть все окна.lnk". В свойствах ярлыка меняем значок на нужный из %windir%\system32\imageres.dll 3. Закрепляем ярлык на панели задач и удаляем с рабочего стола 4. Копируем ярлык C:\Users\имя пользователя\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\Shows Desktop.lnk в каталог C:\Users\имя пользователя\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar и сразу переименовываем этот ярлык в "Свернуть все окна.lnk" (таким образом наш фейковый ярлык будет заменён на правильный) 5. Выполняем Logoff/Logon и проверяем как работает наша кнопка на панели задач.Есть информация, что аналогично можно проделать и с ярлыком Window Switcher.lnk, но я сам этого не проверял.

Теперь мысли по поводу запуска стартового экрана из панели задач. Ряд пользователей жалуются на то, что им не нравится вызывать стартовый экран с помощью функции активных углов, которая в RDP сессии ведёт себя не всегда вменяемо. А кнопка на панели задач вызывающая этот самый стартовый экран обещана только в следующей версии ОС. Поэтому пришлось немного нагрузить нашего программиста, чтобы он слепил нечто подобное. В итоге мы получили маленький исполняемый файл, который фактически эмулирует нажатие кнопки Windows в результате чего вызывается стартовый экран. Загрузить программу можно со страницы на CodePlex. Скопируем файл Start.exe например в каталог %windir% на все наши сервера RDS и на панели задач закрепим ярлык на него.

***

После того как панель задач настроена нужным образом, копируем в отдельную сетевую папку, доступную на чтение всем пользователям, иконки из профиля пользователя под которым выполняли настройку панели задач из папки  %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

Создаем GPP на основе всех параметров реестра в ключе HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband

Сразу все настроенные параметры реестра оптом легко могут быть вставлены в редактор GPP с помощью мастера импорта реестра  - Registry Wizard

Итого по данной задаче в параметрах GPP в разделеUser Configuration\Preferences\Windows Settings\Registry мы создадим группу параметров где сначала удаляем ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband и все вложенные в него параметры, а затем заново создаём этот ключ и устанавливаем предопределённо настроенные параметры

Ну и соответственно в параметрах GPP в разделе User Configuration\Preferences\Windows Settings\Files сначала удаляем все ярлыки из профиля пользователя затем копируем нужные из сетевой папки.

1. Удаление всех файлов *.lnk из профиля пользователя из папки %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

2. Копирование из шары всех файлов *.lnk в профиль пользователя в папку %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

***

Далее, через пользовательские групповые политики выключим отображение иконок в системном трее.User Configuration\Policies\Administrative Templates\Start Menu and Taskbar

***

В конфигурации по умолчанию для панели задач включен самый жесткий режим группировки информации об открытых окнах – Always combine, hide labels

Можно задать единую для всех пользователей настройку группировки в другом варианте, например когда группировка происходит только в том случае, если панель задач заполнена – Combine then taskbar is full. За эту настройку отвечает параметр реестра TaskbarGlomLevel в ключе HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\AdvancedСоздадим в параметрах GPP в разделе User Configuration\Preferences\Windows Settings\Registry соответствующий параметр реестра

***

В итоге мы должны получить примерно следующий вид панели задач

 

Заменяем картинку пользователя по умолчанию

По умолчанию в Windows Server 2012 в качестве картинки пользователя установлено изображение "яйцеголового анонимуса".

Если есть желание как-то изменить эту картинку, например придать ей корпоративный стиль, то для этого нужно заменить 6 файлов расположенных сервере в каталоге %ProgramData%\Microsoft\User Account Pictures\ предварительно создав их в следующем формате:

Имя файла Тип файла Размер (пикселей)
guest bmp 448 * 448
guest png 448 * 448
user bmp 448 * 448
user png 448 * 448
user-200 png 200 * 200
user-40 png 40 * 40

Также можно включить групповую политику Apply the default account picture to all users в разделе Computer Configuration\Administrative Templates\Control Panel\User Accounts после чего заменённые нами изображения будут отображаться для всех вошедших в систему пользователей

 

 

Настраиваем стартовый экран Windows

Входим в систему под любым пользователем и настраиваем стартовый экран (или как его ещё называют Modern UI Start) в том виде, в котором мы хотим его представить всем пользователям без возможности последующей модификации.

Все сделанные настройки стартового экрана сохраняются в бинарном файле appsFolder.itemdata-ms расположенном в профиле пользователя в каталоге%USERPROFILE%\AppData\Local\Microsoft\Windows на том сервере, где выполнялась модификация. То есть, как вы поняли, этот файл не попадает в состав перемещаемого профиля и именно поэтому нужно его брать с того сервера, на котором выполнялась настройка (из локальной копии профиля пользователя). Разместим файл в общедоступной сетевой папке, из которой он будет копироваться в профиль пользователя при его входе на сервера RDS. Установим для этого файла атрибут “Только чтение”.

Создадим в параметрах GPP в разделе User Configuration\Preferences\Windows Settings\Files настройку, которая будет при входе пользователя в систему переписывать этот файл appsFolder.itemdata-ms. Дополнительно можно включить форсированную установку атрибута “Только чтение”

Пример заполнения полей параметра GPP:Source file: \server\MetroStart\appsFolder.itemdata-ms Destination File: %USERPROFILE%\AppData\Local\Microsoft\Windows\appsFolder.itemdata-ms

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

При закреплении ярлыков в стартовом экране, который планируется использовать для всех пользователей есть один неприятный момент, который мне так и не удалось победить. Он заключается в том, что если закреплять ярлыки на полноценно установленные в системе приложения или какие-то системные объекты типа "Панель управления", то они без вопросов будут отображаться у всех пользователей, но вот если закрепить ярлыки на какие-то отдельно взятые папки (локальные или сетевые) или на какие-то исполняемые файлы, незарегистрированные в системе через механизм установки программ (локальные или сетевые), то такие ярлыки у других пользователей отображаться не будут. По этому поводу открыл ветку обсуждения на форуме Technet, но к сожалению решения для W8/WS2012 пока нет. Есть лишь информация о том, что в W8.1/WS2012 R2 ситуация с централизованной настройкой стартового экрана измениться к лучшему и будет решаться связкой инструментария GPO и PowerShell.

 

Создаём групповую политику переопределений для администраторов

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

Применение политики переопределений для администраторов надо ограничить доменной группой безопасности, в которую буду включены учетные запись этих администраторов и убрать назначенную по умолчанию группу Authenticated Users

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

Поделиться ссылкой на эту запись:

Похожее

blog.it-kb.ru

RDS на основе сеансов в Windows Server 2012 R2. Часть 5 — Использование роли шлюза подключений (RD Gateway) — bearded sysadmin

На сегодняшний день количество пользователей, желающих получать доступ к внутренним ресурсам предприятия из дома или кафе, стремительно увеличивается. Такая тенденция наблюдается как в больших корпорациях так и в маленьких компаниях. Поэтому перед системными администраторами всё чаще встает вопрос — а как же удовлетворить потребности пользователей и при этом сохранить безопасность внутренней сети. Для служб RDS таким решением станет использование шлюза доступа к удалённым рабочим столам.

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

В этой статье рассмотрены следующие вопросы:

  1. Как работает шлюз удалённых рабочих столов?
  2. Нововведения в службе RD Gateway в Windows Server 2012
  3. Установка службы RD Gateway
  4. Подключение к коллекции сеансов посредством сервера шлюза

Как работает шлюз удалённых рабочих столов?

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

Рис.1 — Работа шлюза удалённых рабочих столов

Нововведения в службе шлюза удалённых рабочих столов

Нововведений в службе RD Gateway по сравнению с предыдущей версией действительно много и вот самые значительные из них:

  • Добавлена поддержка транспортного протокола UDP
  • Введена возможность изменения стандартных номеров портов для протоколов HTTPS и UDP
  • Добавлена функция использования транспорта HTTP вместо RPC over HTTP

Что же нового приносят эти функции? Давайте разбираться.

Поддержка транспортного протокола UDP

Как известно, для оптимизации передачи трафика по протоколу RemoteFX используется транспортный протокол UDP. Поэтому его поддержка со стороны шлюза значительно улучшает работу с клиентами, использующими для работы именно протокол RemoteFX. В этом случае, кроме стандартных HTTPS создается дополнительный двусторонний UDP-туннель, защищенный протоколом DTLS (детальнее о нём можно почитать тут). Следует заметить, что созданный туннель обеспечивает не только максимальную производительность, но и определённую степень надёжности, что позволяет получать защищенное соединение с довольно приемлемым качеством отображения.

Поддержка изменения стандартных номеров портов для протоколов HTTPS и UDP

По умолчанию для соединения с сервером шлюза удалённых рабочих столов извне используется порт 443, а для связи с внутренними серверами фермы RDS порт 3389. В Windows Server 2012 появилась возможность изменить номера этих портов на нестандартные. Это бывает необходимо в целом ряде сценариев развёртывания.

Поддержка использования транспорта HTTP вместо RPC over HTTP

Для клиентов, которые используют для связи протокол RDP 8.0 предусмотрена возможность использовать транспорт HTTP вместо RPC over HTTP. Недостаток последнего метода транспортировки заключается в том, что процедуры RPC вызываются и при передаче данных от клиента и к нему, что приводит к увеличению излишней нагрузки на ЦП сервера. И как следствие, использование транспорта HTTP позволяет увеличить число одновременных подключений к шлюзу.

Больше об новшествах в службе RD Gateway можно узнать из официального блога разработчиков RDS.

Установка службы RD Gateway

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

Рис.2 — Добавление нового сервера в Диспетчер серверов

Запустить установку роли RD Gateway можно зайдя в Службы удалённых рабочих столов и там либо нажать на ссылку Шлюз удалённых рабочих столов в панели Обзор развёртывания либо в выпадающем меню Задачи на панели Серверы развёртывания выбрать пункт Добавить серверы шлюзов удалённых рабочих столов.

Рис.3 — Добавление шлюза удалённых рабочих столов к развёртыванию

Любое из описанных выше действий приведёт к вызову мастера установки роли шлюза удалённых рабочих столов. В первом окне выбираем сервер или несколько серверов на которые будет установлена роль RD Gateway.

Рис.4 — Выбор сервера для установки роли шлюза

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

Рис.5 — Создание SSL-сертификата для роли шлюза

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

Рис.6 — Окно подтверждения выбора

После того, как сервер добавлен в развёртывание и на него установлены все необходимые службы, потребуется настроить сертификат подлинности. Сделать это можно прямо из окна развёртывания нажав на ссылку Настроить сертификат в уведомлении или позже зайдя в Свойства развёртывания (Диспетчер серверов > Службы удалённых рабочих столов > Общие сведения > Обзор развёртывания > Задачи).

Рис. 7 — Выполнение установки роли службы шлюза

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

Рис.8 — Окно управления сертификатами служб RDS

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

Рис.9 — Создание нового сертификата

После создания сертификата, необходимо применить его, нажав на соответствующую кнопку.

Рис.10 — Успешная установка сертификата для шлюза удалённых рабочих столов

Когда сертификат успешно создан и применен, из окна Ход выполнения (рис.7) можно перейти к свойствам шлюза удалённых рабочих столов. К этим же свойствам можно получить доступ и через Свойства развёртывания.

Окно свойств шлюза RDS позволяет настроить самые основные параметры, а именно: выполнить ли конфигурацию RD Gateway в автоматическом режиме, задать настройки вручную либо вовсе не использовать службу шлюза удалённых рабочих столов. Если выбрана опция Использовать следующие параметры сервера шлюза удалённых рабочих столов, то нижеследующие параметры потребуется указать вручную:

  • Имя сервера. Внешнее имя шлюза к которому обращаются пользователи.
  • Метод входа. Доступны варианты для настройки проверки подлинности пользователя используя пароль или используя смарт-карту.
  • Использовать ли учётные данные шлюза удалённых рабочих столов для удалённых компьютеров.
  • Не использовать сервер шлюза удалённых рабочих столов для локальных подключений. Этот параметр позволяет снизить нагрузку на RD Gateway, т.к. для локальных клиентов соединение с фермой RDS устанавливается минуя шлюз.
Рис.11 — Базовые параметры шлюза удалённых рабочих столов

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

Рис.12 — Службы удалённых рабочих столов после добавления сервера шлюза

Подключение пользователей к ресурсам фермы RDS с помощью шлюза

Все настройки клиента относительно использования шлюза выполняются в окне Подключения к удалённому рабочему столу (mstsc.exe). Для того, чтобы задать клиенту параметры подключения к шлюзу, необходимо на вкладке Дополнительно в разделе Подключение из любого места нажать кнопку Параметры.

Рис.13 — Настройки Подключения к удалённому рабочему столу

Окно параметров содержит в себе ровно те же настройки, что и окно свойств шлюза в настройках развёртывания RDS (рис.11). Здесь указываем полное доменное имя сервера шлюза, метод проверки подлинности, необходимость использования шлюза при подключении в локальной сети и необходимость использования учётных данных шлюза для удалённого компьютера. После нажатия на кнопку Подключить будет выполнено подключение к ферме RDS с помощью шлюза удалённых рабочих столов.

Рис.14 — Параметры подключения к шлюзу удалённых рабочих столов

На Windows RT и Windows 8/8.1 можно осуществлять подключение с помощью приложения Удалённый рабочий стол. Для того, чтобы указать сервер шлюза, через который будет установлено подключение, необходимо зайти в настройки приложения. Сделать это можно в окне приложения, нажав комбинацию клавиш Win+I, или зайдя в пункт Параметры панели Charms.  Из панели параметров необходимо перейти в Параметры соединения, где, среди прочих настроек, можно указать параметры шлюза удалённых рабочих столов.

Рис.15 — Параметры шлюза удалённых рабочих столов в приложении Удалённый рабочий стол

В случае когда развернуты приложения RemoteApp и они подключены средствами Панели управления, приложений Удалённый рабочий стол или GPO, достаточно сперва выполнить обновление приложений (как описано в статье RDS на основе сеансов в Windows Server 2012 R2. Часть 4 — Распространение приложений RemoteApp и удалённых рабочих столов) и затем можно подключаться из внешней сети. Настройки шлюза при этом будут подхватываться в автоматическом режиме.

Для того, чтобы убедиться, что защищенное соединение действительно работает, воспользуемся средствами утилиты netstat. Для этого в командной строке введем netstat -a. Как видим, среди прочих, присутствуют 2 установленных защищенных протоколом HTTPS соединения с узлом rdgw. Вот это и есть подключение к шлюзу удалённых рабочих столов.

Рис.16 — Соединения с шлюзом удалённых рабочих столов

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

Рис.17 — Сведения о шлюзе

***

В этой статье были рассмотрены основные вопросы касающиеся службы шлюза удалённых рабочих столов, а именно процесс работы шлюза и установка роли шлюза в существующее развёртывание RDS. А так же подключение к ресурсам фермы удалённых рабочих столов через шлюз с помощью приложений Подключения к удалённому рабочему столу (mstsc.exe) и Удалённый рабочий стол.

В следующем материале будет рассмотрена настройка серверов шлюзов с помощью инструмента Диспетчер шлюза удалённых рабочих столов.

beardedsysadmin.wordpress.com

Настройка единого входа (RDS 2012 R2 Single Sign On, SSO).

RDS Blog home page

«Технология единого входа (англ. Single Sign-On) — технология, при использовании которой пользователь переходит из одного раздела портала в другой без повторной аутентификации.» — Википедия

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

Чтобы использовать RDS SSO на платформе Windows Server 2012 R2 нужно выполнить ряд действий:

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

 

Во-вторых, на всех серверах с ролью Web Access для каталога RDWeb включить «Проверка подлинности Windows» и отключить «Анонимная проверка подлинности». После внесения  изменений выполнить команду iisreset /noforce.

В-третьих, если настроен шлюз удаленных рабочих столов (RD Gateway), убедиться, что он не используется для внутренних клиентских подключений.

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

Изменить значения по пути «Computer Configuration | Policies | System | Credential Delegation | Allow delegation defaults credential»:

  • Установить значение Enabled, 
  • В поле Optional добавить сервер указав (TERMSRV/<имя сервера, на котором проходит авторизация>). В моем случае TERMSRV/rd.alekssh.com

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

Например, используя заранее подготовленный rdp файл, если это в первый запуск удаленного приложения, то появится:

После этого в правом нижнем углу экрана появится иконка установленной сессии.

Повторной авторизации не потребовалось.

Удаленное приложение запущено (калькулятор) 🙂

Single Sign On можно считать настроенным.

Информация, используемая в этой статье:

http://blogs.msdn.com/b/rds/archive/2012/06/25/remote-desktop-web-access-single-sign-on-now-easier-to-enable-in-windows-server-2012.aspx

http://www.miru.ch/single-sign-on-in-rds-2012-demystified/

Поделиться ссылкой:

Понравилось это:

Нравится Загрузка...

Похожее

Об авторе Alexander Shestakov

MCITP, MCSE. Компания "Динамика"

alekssh.com


Смотрите также

  • Qg15 датчик положения коленвала
  • Ваз 2112 16 клапанов датчик положения коленчатого вала
  • Датчик положения
  • Тюнинг уаз буханка для охоты и рыбалки своими руками
  • Как снять тормозной барабан на уаз буханка
  • Уаз буханка тюнинг салона для рыбалки
  • Уаз буханка устройство автомобиля
  • Кпп уаз буханка устройство
  • Раздатка уаз схема буханка
  • Не заводится уаз буханка карбюратор стартер крутит но не схватывает
  • Тормозная система уаз буханка неисправности