Active Directory Certificate Services. Компьютеру не удается проверить удостоверение шлюза рабочих столов
Active Directory Certificate Services / Argon / Blog
В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации PKI от Microsoft — Active Directory Certificate Services:
Общие представления о PKI
Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:
- Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
- отношения всеобщего доверия к ЦС
- выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
- различные службы поддержки PKI
- списки отзывов сертификатов (CRL)
- сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
- Web Enrollment (средство запроса сертификатов через Web)
Автоматический запрос сертификатов
От центра сертификации нет толку, если клиентские компьютеры в вашей сети не имеют к нему доверия и/или не получают сертификаты. При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС и автоматический запрос сертификатов компьютера у него. Однако, при некоторых сценариях эти политики необходимо настраивать вручную и в этом поможет статья TechNet Configure Computer Certificate Autoenrollment.
Ручная установка сертификата корневого ЦС
Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации. Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:
Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов "server.argon.com.ru". Подключаться к серверам без удостоверений небезопасно. This computer can't verify the identity of the RD "server.argon.com.ru". It's not safe to connect to servers that can't be identified. Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Через MMC
Открыть MMC с правами администратора » добавить оснастку Сертификаты » выбрать в качестве области Локальный компьютер » импортировать нужный сертификат в хранилище Доверенные корневые центры сертификации. Более подробно в статье TechNet Manage Trusted Root Certificates.
Через свойства сертификата
Запустить командную строку с правами админа » вызвать в ней с:\path\to\cert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.
Через командную строку
Потребуется утилита CertMgr, с помощью нее нужно выполнить следующую команду:
certmgr.exe -add -c "с:\path\to\cert.crt" -s -r localMachine root
Проверка отзыва сертификатов
Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.
Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат. A revocation check could not be perfomed for the certificate.
Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:
- CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
- Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)
Для работы обоих вариантов необходимо, чтобы в центре сертификации были заблаговременно настроены доступные из интернета адреса этих служб, так как эти адреса жестко прописываются в каждом выдаваемом сертификате.
Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network. Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.
Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:
certutil -url name.cer
где name.cer — имя выданного сертификата.
Следует иметь ввиду, что проверка отзыва по протоколу OCSP проходит успешно только в том случае, если сертификат ЦС, выдавшего проверяемый сертификат, установлен в хранилище доверенных сертификатов локального компьютера.
Веб-службы регистрации сертификатов
Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:
- запрашивать сертификаты пользователями без участия администратора
- предоставлять по требованию сертификат корневого ЦС
- выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
- делать это все через интернет
- сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС
Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена. An unexpected error has occurred: The Certification Authority Service has not been started.
- та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
- при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS
Запрос сертификата с альтернативным именем
Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).
По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 net stop certsvc net start certsvc
Запрос через консоль MMC
Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…
- В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
- Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
- Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.
Запрос через утилиту certreq
Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq. Чтобы создать сертификат нужно действовать по следующему алгоритму:
1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.
[Version] Signature="$Windows NT$"[NewRequest] Subject = "CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU" KeySpec = 1 KeyLength = 2048 HashAlgorithm = SHA256 Exportable = TRUE MachineKeySet = TRUE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE RequestType = PKCS10 KeyUsage = 0xa0 ProviderName = "Microsoft RSA SChannel Cryptographic Provider" FriendlyName = "server.argon.local with SAN"
[EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes] CertificateTemplate = WebServer
[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=*.argon.com.ru&" _continue_ = "DNS=argon.com.ru&" _continue_ = "DNS=server.argon.local&" _continue_ = "DNS=server&" _continue_ = "DNS=localhost"
2. На машине, для которой предполагается запрашивается сертификат, выполнить команду
certreq -new request.inf
Нам предложат сохранить подготовленный файл запроса в формате .req. Одновременно с этим в хранилище сертификатов компьютера будет сохранен закрытый ключ для будущего сертификата.
3. Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).
4. Выполнить установку полученного сертификата на целевой компьютер следующей командой
certreq -accept request.cer
5. PROFIT. В результате описанных действий в хранилище сертификатов компьютера будет создан сертификат с закрытым ключом, пригодный для авторизации сервера по нескольким именами, прописанным .inf файле.
Обобщенные лучшие практики
Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2
- На контроллере домена развернут корневой центр сертификации
- Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
- В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
- На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
- Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
- Online Responder для проверки отзыва сертификатов по протоколу OCSP
- Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
- Remote Desktop Gateway
- Outlook Web Access
- DirectAccess
- SharePoint
Полезные ссылки
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
В связи с недавними обновлениями безопасности Windows, закрывающее уязвимости в протоколе CredSSP, парочка маков (mac mini середины 2007 года) потеряли доступ к терминальному серверу на базе Windows Server 2008R2.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.Дело в том, что старая версия маковского rdp client 2.1.1 от Microsoft, ставшая последней доступной для Mac OS X 10.7 (Lion), не работает не только с Windows Server 2012, но после вышеупомянутого обновления перестала подключаться и к WinServer 2008R2. В природе существует и неофициальная версия rdp-клиента 2.1.2, однако разыскивать её, нет особого резона — результат будет аналогичным.
Установка галки «Подключаться даже если проверка подлинности завершается с ошибкой» в настройках RDP клиента (Свойства -> Безопасность) тоже никак не влияет на результат подключения.
Актуальные, на данный момент, клиенты Microsoft Remote Desktop 8.0 (совместима с OS X 10.9 и выше) и Microsoft Remote Desktop 10.0 (macOS 10.10 и выше) поставить на старую систему OS X не представляется возможным. Из вменяемых альтернатив, можно выделить, пожалуй, только Parallels Client... и вроде вот оно счастье, ведь в минимальных требованиях значится Mac OS X 10.7.3, однако не стоит верить всему что пишут. Хоть программа и благополучно устанавливается, позволяет внести данные о вашем подключении, однако вылетает на попытке соединения с сервером вываливая кучу ошибок.
От безысходности можно пойти от обратного, изменив работу службы удаленных рабочих столов на сервере (метод работает и на Windows Server 2012), однако лучшим вариантом станет замена клиентской машины.
Подключения старой версии rdp client 2.1.1 к Windows Server 2012
Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:
Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Безопасность
Здесь следует поменять значение двух параметров:
- Требовать использования специального уровня безопасности для удаленных подключений по методу RDP (ставим "Включить", а уровень безопасности выбираем "RDP")
- Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (ставим "Отключить")
Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.
Если считаете статью полезной,не ленитесь ставить лайки и делиться с друзьями.
mdex-nn.ru
Решение проблемы подключения RDP клиента к Server 2012
Делал терминальный доступ на Windows Server 2012 R2 и решил извратиться, сменив порты доступа с дефолтных на пятизначные, для затруднения обнаружения оных в результате сканирования портов.
И тут возникла проблема, что люди не могут залогиниться с Mac OS, при этом к имевшимся уже в наличии Server 2008 логинятся нормально. А в случае 2012 винды, сторонние RDP клиенты просто не видят сервера, а родной RDP клиент для Mac OS говорит, что “Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение” либо еще какие нить ошибки.
С родного виндового RDP клиента, из под 7ки, вообще никаких проблем.
Сначала решил было, что это проблема работы на измененных портах, но дефолтные RDP также не оживили ситуацию.
черный экран RDP клиента при подключении к Windows Server 2012
Погуглив, выяснил, что старые версии макаковского RDP клиента не поддеррживаются в Server 2012 и поэтому надо ставить 8.X+. В данный момент актуальная версия MS RDP for Mac 8.0.14, которая в свою очередь просто стала виснуть на установлении сессии. Не помогла и галка в настройках RDP клиента Свойства -> Безопасность -> Подключаться даже если проверка подлинности завершается с ошибкой. Причем на мелкомягком сайте народ в основном матерился на последние версии клиента 8.013 и 8.0.14.
В связи с чем решил идти от обратного и вместо того, чтобы закручивать гайки для RDP соединения с Server 2012 немного их ослабить.
Вызываем обшиву групповых политик Ctrl+R -> gpedit где проходим в раздел настроек безопасности RDP: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Dekstop Session Host
после чего меняем значения двух параметров:
Require use of specific security layer for remote desktop (RDP) connection = EnableRequire user authentication for remote connections by using Network Level Authentication = Disable
В таком варианте Microsoft Remote Desktop app, даже старой версии, начинает подключаться к RDP Server 2012, но только по дефолтному порту 3389, т.к в случае его изменения на нестандартный, не проходит пароль.
Для того чтобы заработал RDP клиент и на нестандартном порту, пришлось изменить еще несколько значений, как на изображении.
Настройки безопасности RDP на Windows Server 2012 для корректной работы MaC OS клиентов
VN:F [1.9.21_1169]
Rating: 10.0/10 (5 votes cast)
VN:F [1.9.21_1169]
Rating: +3 (from 3 votes)
Проблема подключения Mac- клиента RDP к Server 2012, 10.0 out of 10 based on 5 ratingsТеги: rdp
odminblog.ru
