Вадим, спасибо за статью, но к сожалению она не полна :( Всё ещё более запущено :) Причина о которой говорится в статье, она действительно возникает из-за отсутствия корневого сертификата в доверенных. Решение не всегда такое тривиальное, добавил и всё. Решение необходимо искать в том, чтобы пользователи (ПК пользователей) могли видеть корневой сервер сертификации (или его подчинённого). В нашем случае (были такие же большие грабли), пользователи имели в доверенных сертификаты корневого сервера сертификации, но, но и не работало. Пока на активном оборудовании не было организован доступ на сервер сертификации (а он у нас в корневом домене был), пользователи получали такие сообщения. Так же существует проблема в том, как подписать сертификат. Самоподписанный (самодоверенный) сертификат работает, но срок его мал. в добавок ко всему, в случае использования фермы, необходим сертификат выданный на имя фермы. Так ещё в свойствах его необходимо указать что выдан для "Проверки подлинности сервера". В некоторых документах указано что необходимо чтобы был подписан как 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 не фиксирует. Т.е. клиент принимает решение о невозможности проверки на основе непонятно чего. Я в растерянности и уже не знаю куда рыть.