Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Вимоги для доступу до термінального сервера

Читайте также:
  1. Вимоги до виконання індивідуального завдання.
  2. ВИМОГИ ДО екзамену
  3. Вимоги до особистості й освіти тренера
  4. ВИМОГИ ДО ОФОРМЛЕННЯ ЗВІТУ З ВИРОБНИЧОЇ ПРАКТИКИ
  5. Вимоги до паспорта
  6. Вимоги до розрахунку та формування резерву за цінними паперами в портфелі банку до погашення

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

Право AllowlogonthroughTerminalServices (дозволено вхід через службу терміналів) – у Windows 2000 необхідно б було надавати право Logonlocally усім користувачам, яким би був потрібен доступ до термінального сервера. Це створювало потенційний пролом у безпеці, оскільки дозволяло б реєструватися на консолі сервера, обходячи обмеження, що ви зробили для RDP. WS2K3 розділяє право локального входу і право входу через службу терміналів. За замовчуванням на WS2K3 право AllowlogonthroughTerminalServices дається тільки адміністраторам і членам групи RemoteDesktopUsers.Права використовувати RDP – адміністратор може встановити дозвіл RDP за допомогою TerminalServicesConfiguration.

Опція Allowlogontoterminal (дозволено вхід на термінальний сервер) – у властивостях кожного користувача в AD є опція Allowlogontoterminalserver, що визначає, чи дозволено користувачеві реєструватися на термінальному сервері. Зазамовчуваннямцяопціявключена.

Allow Log On Through Terminal Services

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

Вкладка Permissions властивостей з'єднання RDP-Tcp показує, що право використовувати RDP дозволено адміністраторам і членам групи RemoteDesktopUsers. За замовчуванням група RemoteDesktopUsers порожня, тому щоб дозволити користувачам під’єднуватися до термінального сервера, необхідно додати їх у цю групу.

RDP надає три основних рівні доступу: GuestAccess (гість), UserAccess (користувач) і FullControl (повний доступ).

Allow Logon to Terminal Server

Остання вимога для реєстрації на термінальному сервері робиться на рівні користувачів. У властивостях користувачів є чотири вкладки, що відносяться до налаштувань термінального сервера. Більшість із них налаштовують проходження сеансу при під’єднанні користувача до термінального сервера.

Налаштування облікових записів користувачів.

Поки розглядаємо інтерфейс UserProperties, давайте опишемо інші налаштування термінального сервера. Більшість із цих налаштувань доступні в TerminalServicesConfiguration. Ви самі вирішуєте, на якому рівні їх застосовувати – для окремих користувачів або до сервера. Потрібно враховувати, що налаштування користувача визначають налаштування сервера. Для доступу до користувацьких налаштувань використовуйте один із наступних інструментів: для доменів AD – інструмент ActiveDirectoryUsersandComputers; для доменів NT 4.0 – UserManagerforDomains, а для робочих груп – ComputerManagement.

х сеансів. Ви можете вибрати поведінку при втраті з'єднання або перевищенні ліміту часу сеансу – від'єднати сеанс або завершити його.

Також можна вибрати, чи може користувач під'єднуватися до роз'єднаного сеансу з будь-якого клієнтського пристрою або тільки з того, з якого був ініційований сеанс.

Домашній каталог і каталог профілю

ОС Windows дозволяє працювати з мережевими домашніми каталогами і переміщуваними профілями. Ці особливості Windows дозволяють підтримувати центральне сховище для користувацьких документів і налаштувань профілю, щоб вони були доступні незалежно від комп'ютера, за яким сидить користувач.

TerminalServices може підтримувати різні сховища для домашніх даних і профілів користувачів.

Шлях до профілю TerminalServices

При реєстрації користувача на робочій станції, система перевіряє атрибут ProfilePath об'єкта користувача. Якщо користувач має профіль, що централізовано зберігається, і цей профіль новіший, ніж його локально кешована копія, то профіль завантажується для цього користувача. Аналогічно, коли користувач реєструється на термінальному сервері, система запитує атрибут UserParameters і шукає TerminalServicesProfilePath.

Цей поділ дозволяє підтримувати різні профілі користувачів залежно від того, який тип комп'ютера вони використовують. У більшості випадків ви захочете отримати переваги профілів TerminalServices, оскільки деякі функції TerminalServices ускладнюють роботу, якщо ви не використовуєте профілі TerminalServices. Це можна пояснити на такому прикладі. Якщо ви не використовуєте переміщувані профілі для ваших користувацьких робочих станцій, то залежите від підтримки комп'ютером копії користувацького профілю. Якщо користувач не реєструється на кількох ПК, ці налаштування працюють прекрасно. Однак на термінальному сервері відмовлення від використання переміщуваних профілів означає, що термінальний сервер повинен підтримувати профілі для всіх користувачів, що вимагає багато дискового простору. Крім того, якщо ви хочете використовувати розподіл навантаження і каталог сеансів для розподілу користувачів за кількома термінальними серверами, вам доведеться підтримувати профілі користувачів на кожному сервері.

Використання профілів TerminalServices дозволяє користувачеві отримувати однакові налаштування незалежно від того, до якого сервера він підключається. Для запобігання проблем з дисковим простором можете дозволити системну політику, що видаляє локальні закешовані копії переміщуваних профілів.

Якщо ви не вказали термінальний профіль, але вказали переміщуваний профіль Windows, термінальний сервер буде використовувати переміщуваний профіль Windows. Крім того, якщо термінальний профіль зазначений, але недоступний, система повернеться до профілю Windows. Ця поведінка може викликати небажані результати, якщо ви використовуєте на сервері сценарії сумісності додатків.

Якщо ви використовуєте переміщувані профілі Windows, використання профілів TerminalServices може стати більш важливим, оскільки, якщо система не знаходить шляху до термінального профілю в обліковому записі користувача, він шукає шлях до профілю Windows.

Місцезнаходженя також може стати причиною поділу профілів. Швидше за все, ви захочете зберігати користувацькі профілі Windows на файлових серверах ближче до робочих станцій, але термінальні сервери через їх невисокі вимоги до пропускної здатності можуть знаходитися в центрах даних. WS2K3 має дві нові політики, що керують користувацькими профілями.

Allowonlylocaluserprofiles запобігає зазначеному комп'ютерові завантажувати переміщувані профілі, навіть якщо вони сконфігуровані для користувачів.

SetPathforTSRoamingProfiles дозволяє вказати специфічний файловий сервер, що буде використовуватися для переміщуваних профілів усіх користувачів, які реєструються на термінальному сервері.

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

Можна налаштувати облікові записи користувачів так, щоб при реєстрації на термінальному сервері вони використовували інші домашні каталоги. Система використовує користувацький домашній каталог на ROOTDRIVE і зберігає там скріпти сумісності додатків. Окремі домашні каталоги для терміналів дозволяють тримати файли поза домашнім каталогом Windows користувача. Проблема полягає втому, що коли ваш користувач зберіг свої документи в домашньому каталозі Windows, то користувачеві необхідний доступ до того ж каталога при реєстрації на термінальному сервері. Якщо визначили маршрут до домашнього каталога TerminalServices, цей маршрут буде застосовуватись замість домашнього каталога Windows. Якщо не вказати домашній каталог TerminalServices, то буде використовуватися домашній каталог Windows.

Налаштування властивостей користувачів через інтерфейс ActiveDirectoryService

Використання графічних утиліт для конфігурації користувачів зручно, але якщо необхідно конфігурувати велике число користувачів, то легше це робити з використанням інтерфейсу служби активного каталога (ActiveDirectoryServiceInterfaces, ADSI). У порівнянні з Win2K ця особливість значно поліпшена.

Доступ до ADSI здійснюється через WindowsScriptHost (WSH), тому можна використовувати скріпти на VisualBasicScript (VBScript) або JavaScript. Конфігурування користувачів через ADSI складається з трьох етапів. Спочатку потрібно відкрити з'єднання з обліковим записом користувача, потім встановити властивості, і, нарешті, записати зміни в обліковий запис користувача. Для відкриття з'єднання використовуємо провайдери WinNT, або LDAP. Провайдер WinNT використовується записами SecurityAccountsManager (SAM) – локальними обліковими записами на термінальному сервері, чи записами в домені NT 4.0. LDAP використовується для облікових записів користувачів в АD.

Хоча ви можете використовувати ці скріпти для конфігурування облікових записів домену NT 4.0 та Win2KAD, все ж запустити їх можете тільки на сервері WS2K3. Вони не будуть працювати на Win2K і навіть на WindowsXP.

Звичайно, якщо потрібно сконфігурувати один обліковий запис, то швидше і простіше це зробити графічною утилітою, але ADSI зручний для одночасного конфігурування властивостей для багатьох користувачів.

Групова політика

WS2K3 включає новий рівень гнучкості при конфігуруванні користувацьких сеансів – групові політики. Як ви вже знаєте, ви можете конфігурувати тайм-аути сеансів, налаштування ресурсів клієнта, опції відновлення з'єднання для індивідуальних користувачів або окремих серверів. За допомогою групових політик WS2K3 ви також можете керувати всіма цими опціями за допомогою GPO.

Для підвищення гнучкості ці налаштування можна конфігурувати для користувачів і для комп'ютерів. Тому можна встановлювати всі опції для всіх серверів з центрального місця. Можна навіть застосовувати GPO до окремих груп безпеки, щоб адміністратори мали доступ до інших опцій.

 

Рисунок 3.1.1 – Налаштування групової політики

 

Якщо необхідно встановити опції в кількох місцях, або ви мігруєте з існуючої термінальної інфраструктури Win2K і вже сконфігурували ваших користувачів і сервери, то слід знати пріоритет цих опцій:

1. Налаштування Computer Configuration Group Policy.

2. Налаштування User Configuration Group Policy.

3. Налаштування утиліти Terminal Services Configuration.

4. Налаштування користувацького облікового запису.

Будуть перемагати налаштування з більш високим пріоритетом, тому в Computer Configuration можна перевизначати налаштування User Configuration і т.п.


Дата добавления: 2015-11-30; просмотров: 78 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.009 сек.)