Проблема с проверкой подлинности протокола RDP
  | Список форумов SYSAdmins.RU -> WINDOWS |
| Автор | |||
|---|---|---|---|
| Good3Win Новичок Зарегистрирован: 26.01.2010
|
| ||
| Вернуться к началу |
| ||
 | |||
| Зарегистрируйтесь и реклама исчезнет! | |||
| |||
| Good3Win Новичок Зарегистрирован: 26.01.2010
|
| ||
| Вернуться к началу |
| ||
| |||
| Odin.TMD Участник форума
Зарегистрирован: 12.08.2004 |
| ||
| Вернуться к началу |
| ||
| |||
| roverwolk Новичок Зарегистрирован: 18.09.2012
|
| ||
| Вернуться к началу |
| ||
| |||
| MrCarnat Новичок Зарегистрирован: 14.02.2014
|
| ||
| Вернуться к началу |
| ||
| |||
| Ekzar Новичок Зарегистрирован: 30.07.2012 Не удалось проверить не был ли отозван этот сертификат rdp windowsВ различных интернетах всё ещё задают (и не мало) вопросы про проблемы подключения через remote desktop к серверу терминалов защищённому SSL сертификатом. При подключении пользователи видят вот такое: И сообщение: A revocation check could not be performed for the certificate. Или в русском варианте — не удалось проверить не был ли отозван этот сертификат. А если нажать на View certificate… выясняется, что всё в порядке, сертификат доверен и цепочка построена правильно. Что это такое и как с этим жить? Причины здесь может быть 2:
Эта проблема встречается примерно в 60-70% случаев появления этой ошибки. Многие привыкли устанавливать корневые сертификаты по двойному клику в пользовательское хранилище. Но, новый mstsc.exe проверяет цепочку сертификатов так, чтобы она заканчивалась на доверенном корневом сертификате установленном в компьютерном хранилище. Поскольку сертификат недоверенный, certificate chaining engine даже и не пытается проверить что-то на отзыв. Как установить сертификат туда:
Когда сертификат выдаётся внутренним CA, но пользователи подключаются к серверу через интернет (например из дома подключаются к RemoteApp по https), очень часто файлы сертификатов и CRL’ы издающего CA недоступны из интернета. В данном случае необходимо связаться с системным администратором, чтобы он переконфигурировал расширения CDP так, чтобы CRL’ы были доступны и из интернета. Что бы почитать? Comments:Вадим, спасибо за статью, но к сожалению она не полна 🙁 Всё ещё более запущено 🙂 Причина о которой говорится в статье, она действительно возникает из-за отсутствия корневого сертификата в доверенных. Решение не всегда такое тривиальное, добавил и всё. Решение необходимо искать в том, чтобы пользователи (ПК пользователей) могли видеть корневой сервер сертификации (или его подчинённого). В нашем случае (были такие же большие грабли), пользователи имели в доверенных сертификаты корневого сервера сертификации, но, но и не работало. Пока на активном оборудовании не было организован доступ на сервер сертификации (а он у нас в корневом домене был), пользователи получали такие сообщения. Так же существует проблема в том, как подписать сертификат. Самоподписанный (самодоверенный) сертификат работает, но срок его мал. в добавок ко всему, в случае использования фермы, необходим сертификат выданный на имя фермы. Так ещё в свойствах его необходимо указать что выдан для «Проверки подлинности сервера». В некоторых документах указано что необходимо чтобы был подписан как Remote Desktop Connection (вот в названии могу ошибиться). Так и этого мало, шаманство так ни к чему не привело, не знаем как правильно подписать 🙁 чтобы при использовании credssp можно было пользоваться SSO. Ещё нашли одну проблему, которая решена в других языках (англ, нем, и т.д.), но только не в русской версии. Для Windows XP SP3 при включении протокола CredSSP для работы с SSO, пользователи могут входить без доп ввода пароля в терминальные сервера, но только не в ферму серверов :(( Проблема в библиотеке kerberos.dll и ещё одной, точно не помню, которую решил мелкософт, выпустив патч который можно получить по запросу, для всех других языков ещё в мае 2009 года. Борьба с протоколом и сертификатами сводит на нет всё преимущество данной технологии от мелкософта. Всё как то запущено. К сожалению и библиотеки в технете не полны, не раскрывают суть, а только поверхностно. Вот как найти информацию по сертификату? Как подписать, какие поля важны. Как решить проблему со входом в ферму и т.д. > Пока на активном оборудовании не было организован доступ на сервер сертификации а зачем это? Сервер CA должен публиковать свои CRT и CRL файлы на публично доступный веб-сервер. Сам CA в данном случае не нужен, а нужны только его файлы для построения цепочек и проверки сертификатов на отзыв. >Сервер CA должен публиковать свои CRT и CRL файлы на публично доступный веб-сервер. Вадим, суть в том, что этот веб сервер он есть, и н подчинёный, и находится в корневом домене, из под поддомена где мы, его небыло видно через активное оборудование. Пока служба (крутящая активное оборудование), не открыла на него доступ (на подчинёный) ничего не работало 🙁 и это при большой домменой структуре. в то же время не позволено поднимать в своём домене подчинёный центр сертификации. А если учитывать что необходимо пользователям работать с фермой терминальных серверов, и проверка сертификата обязательна (Win2k8R2, credSSP, SSO), то и получали такую проблему. 700-800 человек не могли просто работать, как только ставили сертификат подписанный для фермы. Убрали и поставили по умолчанию самоподписанный, стали худо бежно входить. В то же время, всем нужно SSO, не нравится им (да и кому понравиться) что в ферму необходимо авторизоваться дважды, первый раз чтоб переслали на сервер, второй, уже на сам сервер 🙁 Пробовал исправление англ на русскую ХР поставить, не получается, просто замена kerberos.dll не получается, необходимо чтобы эта библиотека была свободна. Уж и не знаем, когда такую проблему исправят. На англ версию ХР патч ставится, и работает SSO на ура, как и должно, а вот на руссиш нет такого исправления 🙁 в данном случае у вас проблема не технического, а административного характера. Без публичного веб-сервера вам не выкрутиться из сложившейся ситуации. что касается SSO, тут я ничего не могу сказать, т.к. локализованные системы не использую нигде. Решение в принципе найдено: Доступ на сервера сертификации предоставлен, сертификат теперь проверяется и ошибок нет. SSO на CredSSP.dll работает с фермой: необходимо установить два патча — kb953760 и kb953760-v2 которые патчат (впервые такое вижу) kerberos.dll и msv1_0.dll. Версии самих dll в этих исправлениях лежат старые 5.1.2600.5615 версии QFE. Но после применения этих патчей, версии dll остаются какие были в системе (5.1.2600.5834 что ли), но содержимое в них уже изменено по сравнению с оригинальными GDR файлами (что идут с сервис паком 3). Впервые вижу чтобы содержимое патча одно, после применения его, версионность библиотек остаётся той же самой (меняется только версия QFE с GDR). Были в системе 5.1.2600.5834 GDR, так и остались 5.1.2600.5834 но уже QFE. Финт ушами, и никакого машеничества. Зато, нарушений в работе библиотеки не замечено, и проблемы с попаданием в ферму решены. Но, самую главную роль играет опять же сертификат, который должен быть правильно подписан (ох уж он, сертификат). Стоит ошибиться в нём, как всё снова не работает (но оно так и должно быть). Всё это потому, что главную роль играют уже сами сертификаты. >Версии самих dll в этих исправлениях лежат старые 5.1.2600.5615 версии QFE. Но после применения этих патчей, версии dll остаются какие были в системе (5.1.2600.5834 что ли), но содержимое в них уже изменено по сравнению с оригинальными GDR файлами (что идут с сервис паком 3). возможно, здесь найдете объяснение сему факту: http://pronichkin.com/Lists/Posts/Post.aspx?ID=85 Вадим, подскажите с чем может быть связана еще подобная ошибка? Я свою проблему описывал на форуме TechNet — http://bit.ly/fBV4HU В кратце: проверка сертификата ручками(certutil -url . ) дает положительный результат. и по OCSP и по CRL. А RDP Win7 ругается. %) попробуйте на этом компьютере выполнить certutil -urlcache CRL delete очистка реестра + ребут помогли. Спасибо! Бился с этим месяц. %) В моём случае корневой сертификат где надо, CRL доступен по http, проверка сертификата сервера на клиентском компьютере командой certutil -veryfy -urlfetch cert.cer проходит, сниффером вижу, как клиент в этот момент лезет по http на ссылку, описанную в расширении CDP сертификата. При коннекте к терминалу, однако, клиент выдаёт вышеозначенную ошибку, при этом сниффер попыток обращения к CDP не фиксирует. Т.е. клиент принимает решение о невозможности проверки на основе непонятно чего. Я в растерянности и уже не знаю куда рыть. © 2008 — 2021 — Sysadmins LV. All rights reserved | |||
