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

Для системного администратора

С момента выпуска компанией Microsoft Windows 2000, стали доступными некоторые возможности по делегированию. Концепции делегирования могут быть немного запутанными, но в своей основе делегирование – является залогом эффективности работы. Без использования делегирования вы сможете использовать лишь группы по умолчанию, которые обладают административными правами на определенные объекты и задачи.

Например, если не использовать делегацию для групп и учетных записей пользователей, то пользователя необходимо поместить в группу Account Operators (операторы учетных записей), чтобы он имел возможность просто управлять пользователями, группами и компьютерами в домене. Конечно, пользователя также можно поместить группы Domain Admin (администраторы домена) или Enterprise Admin (корпоративные администраторы), но в результате этого мы дадим ему слишком много прав для простого управления учетными записями.

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

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

Технология 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 на клиенте посылает учетные данные пользователя на сервер.

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

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

Настройка параметров политики учетных записей

Средствами созданной в консоли ММС консоли Политика «Локальный компьютер» (Local Group Policy) настраиваем следующие параметры Политики учетных записей (Account Policy):

пользователь должен сменить не менее пяти различных паро­лей, прежде чем сможет повторно использовать старый пароль;

после смены пароля должно пройти 24 часа, прежде чем пользо­ватель сможет снова сменить пароль;

Вам не нужна значка рабочего стола для рабочего стола

Существуют и другие способы свести к минимуму все ваши окна.

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

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

РЕШЕНИЕ:
Настройка проводится на ЛОКАЛЬНОЙ МАШИНЕ пользователя, с которой будет производиться подключение Серверу удаленных рабочих столов.
Пуск- Выполнить либо Win+R и вводим команду gpedit.msc
В открывшемся окне редактора локальной групповой политики идем в раздел «Административные шаблоны» -> «Система» -> «Передача учетных данных». Нас интересует политика «Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера (только NTLM)»

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

Заполнять список можно несколькими способами. Например:
• TERMSRV/удаленный_пк — разрешаем сохранять учетные данные для одного конкретного компьютера;
• TERMSRV/*.contoso.com — разрешаем сохранять данные для всех компьютеров в домене contoso.com;
• TERMSRV/* — разрешаем сохранять данные для всех компьютеров без исключения.
Внимание: используйте в TERMSRV заглавные буквы, как в примере. Если указан конкретный компьютер, то значение удаленный_пк должно полностью совпадать с именем, введенным в поле «Компьютер» удаленного рабочего стола.

Заполнив список жмем OK и закрываем редактор групповых политик. Открываем командную консоль и обновляем политики командой gpupdate /force. Все, можно подключаться.
И еще. Используя локальные групповые политики мы разрешаем сохранять учетные данные только на одном конкретном компьютере. Для нескольких компьютеров будет лучше создать в домене отдельное OU и привязать к нему соответствующую доменную политику.

РЕШЕНИЕ:
Открыть порт 443, на стороне сервера (и клиента на локальной машине, если закрыт). Произвольный открытый порт (к примеру, 1689), будет возможно настроить, только когда у всех пользователей установлен Windows 7 SP1 (т.к. только там поддерживается RDP 8, в котором можно писать адрес сервера с портом. К примеру 95.181.24.134:1689). Из более ранних версий RDP, подключится будет невозможно.