none
RD Gateway и сертификаты RRS feed

  • Общие обсуждения

  • Здравствуйте!

    Есть проблема с сертификатами для шлюза удалённых рабочих столов.

    У нас два разных домена в разных подсетях. domain1.local (подсеть 10.0.0.0/24) и domain2.local (подсеть 10.1.1.1/24)

    Между сетями поднят файрволл с натом. Внешний адрес 10.2.2.1

    В сети domain2.local поднята ферма терминальных серверов и шлюз удалённых рабочих столов на Server 2012R2. В domain2.local есть центр сертифкации.

    Для того что бы из сети domain1.local зайти на какой либо из серверов сети domain2.local мы коннектимся на внешний адрес файрвола 10.2.2.1:порт -> адрес нужного сервера:порт в сети domain2.local т.к. ходить нужно именно через nat по соображениям безопасности.

    Для клиентов в сети domain1.local шлюз удалённых рабочих столов в сети domain2.local резольвится днсом как 10.2.2.1

    Для шлюза терминальных серверов выписывается сертификат в котором: 

    Субъект CN = terminal-gateway.domain.local

    Дополнительное имя субъекта IP-адресс = 10.2.2.1 (адресс файрвола)

    На клиентских компьютерах в сети domain1.local центр сертификации domain2.local добавлен  в доверенные корневые центры сертификации.

    При подлкючении по RDP из сети domain1.local  на ферму терминальных серверов с использованием шлюза удалённых рабочих столов, возникает ошибка: "Не удалось подключиться к удалённом компьютеру, поскольку сертификат сервера шлюза удалённых рабочих столов просрочен или отозван. Обратитесь к администратору сети."

    Если нажать на "Просмотреть сертифкат" то там отображается валидный сертифкат описанный выше который выдавался центром сертифкации . Этот сертифкат указан как сертифкат для шлюза удалённых рабочих столов в оснастке Deployment Properties в Server manager -> Remote Desktop Services.

    Он же указан в RD gateway Manager.


    • Изменено Ilya Matveikin 2 февраля 2015 г. 12:11
    • Изменен тип Alexander RusinovModerator 16 февраля 2015 г. 13:53 Отсутствие активности в течении нескольких дней
    2 февраля 2015 г. 12:10

Все ответы

  • Здравствуйте,
    Для начало попробуйте ознакомиться со статьей:
    http://blogs.msdn.com/b/rds/archive/2008/12/18/ts-gateway-certificates-part-iii-connection-time-issues-related-to-ts-gateway-certificates.aspx возможно у Вас схожая проблема.

    Best Regards, Andrei ...
    Microsoft Certified Professional

    • Изменено SQxModerator 2 февраля 2015 г. 12:51 исправлено
    2 февраля 2015 г. 12:50
    Модератор
  • Спасибо за ответ. Данную статью я уже читал. Сертефикат выдан сегодня сроком на год  и вряд ли может быть просрочен. Срок действия до 02.02.16

    Время и временные зоны на всех серверах и рабочих станциях обоих доменов идентичны.

    2 февраля 2015 г. 13:15
  • На клиентских компьютерах в сети domain1.local центр сертификации domain2.local добавлен  в доверенные корневые центры сертификации.

    Как вариант - сертификат ЦС добавлен только в пользовательское хранилище доверенных корневых. В этом случае, при просмотре под пользователем сертификатов, подписанных таким ЦС, они будут валидными всегда. А вот работать это будет не всегда. Попробуйте явно поместить (переместить) сертификат ЦС в компьютерное хранилище (контейнер Доверенных корневых ЦС).

    S.A.

    2 февраля 2015 г. 13:20
  • Спасибо за совет, но не помогло. Было предположение, что компьютеры из домена domain1.local не могут проверить в центре сертификации домена domain2.local не отозване ли сертификат, но оказалось, что есть доступ и можно из домена domain1.local можно получить список http://domain2.local/pki/SUB-CA01.crl
    2 февраля 2015 г. 13:29
  • 1) В качестве клиентских машин какая ОС используется?
    2) На шлюзе сертификат как проверенный (доверенный) определяется или как не проверенный (не доверенный)?

    Best Regards, Andrei ...
    Microsoft Certified Professional

    2 февраля 2015 г. 13:57
    Модератор
  • Клиенты win 7, mstsc версия 6.3.9600.16415

    На шлюзе сертификат определяется как доверенный.

    2 февраля 2015 г. 14:00
  • В сертификате прописаны SAN-имена терминальных серверов?

    Innovation distinguishes between a leader and a follower - Steve Jobs

    2 февраля 2015 г. 14:16
  • Посмотрите статью возможно Ваш случай Remote Desktop Client 7 и revocation checking

    Best Regards, Andrei ...
    Microsoft Certified Professional

    2 февраля 2015 г. 14:25
    Модератор
  • В сертификате прописаны SAN-имена терминальных серверов?

    Innovation distinguishes between a leader and a follower - Steve Jobs


    Нет, их там быть не должно. Имена терминальных серверов прописаны в сертификате брокера.
    2 февраля 2015 г. 14:27
  • А точка распространения списков отзыва этого ЦС (который в domain2), как она прописана в сертификатах, из сети domain1 доступна?


    Слава России!

    2 февраля 2015 г. 14:47
  • А точка распространения списков отзыва этого ЦС (который в domain2), как она прописана в сертификатах, из сети domain1 доступна?


    Слава России!

    да, я писал ранее "из домена domain1.local можно получить список http://domain2.local/pki/SUB-CA01.crl"

    Советы из статьи Remote Desktop Client 7 и revocation checking так же пробовал выполнить, не помогло.

    3 февраля 2015 г. 13:29
  • 1) Уточните пожалуйста для полного понимание клиентские компьютеры находятся в домене или принадлежат некой рабочей группе?
    2) У клиентских компьютерах прописаны днс-сервера домен контроллеров либо используются какие-то публичные?

    Best Regards, Andrei ...
    Microsoft Certified Professional

    3 февраля 2015 г. 13:45
    Модератор
  • 1) Клиентские компьютеры находятся в домене domain1.local о чём написано в моём первом сообщении.

    2) У клиентских компьютеров прописаны свои DNS сервера. Но имена  terminal-gateway.domain.local и CA.domain2.local - адресс центра сертификации, резолвятся через файл hosts на клиентах.

    3 февраля 2015 г. 14:17
  • 1) А как вариант пробовали передернуть службу RDS после изменений?
    2) Также на клиентских машинах указываете в параметрах rd gateway, либо настроено получать автоматически?

    Best Regards, Andrei ...
    Microsoft Certified Professional

    • Изменено SQxModerator 3 февраля 2015 г. 14:59 добавлено
    3 февраля 2015 г. 14:40
    Модератор
  • да, я писал ранее "из домена domain1.local можно получить список http://domain2.local/pki/SUB-CA01.crl"

    Советы из статьи Remote Desktop Client 7 и revocation checking так же пробовал выполнить, не помогло.

    Извините, я, когда писал, этот пост ещё не видел.

    Тогда придётся диагностировать поподробнее.

    Подключитесь к шлюзу RD браузером (например IE) по URL https://terminal-gateway.domain.local/rpc/rpcproxy.dll (при подключении будут запрошены данные для аутентификации, а после подключения вы получите пустой экран) и сохраните сертификат подключения в файл на клиенте.

    После чего проверьте сертификат командой

    certutil -verify -urlfetch имя_файла_с_сертификатом


    Слава России!

    3 февраля 2015 г. 15:40
  • да, я писал ранее "из домена domain1.local можно получить список http://domain2.local/pki/SUB-CA01.crl"

    Советы из статьи Remote Desktop Client 7 и revocation checking так же пробовал выполнить, не помогло.

    Извините, я, когда писал, этот пост ещё не видел.

    Тогда придётся диагностировать поподробнее.

    Подключитесь к шлюзу RD браузером (например IE) по URL https://terminal-gateway.domain.local/rpc/rpcproxy.dll (при подключении будут запрошены данные для аутентификации, а после подключения вы получите пустой экран) и сохраните сертификат подключения в файл на клиенте.

    После чего проверьте сертификат командой

    certutil -verify -urlfetch имя_файла_с_сертификатом


    Слава России!

    Спасибо! Всё таки недоступен был список отзыва сертификатов, что странно, ибо на этот случай обычно возникает ошибка о невозможности проверить отозван ли был сертификат.

    Теперь возникает ошибка: Не удалось подключиться к удалённому компьютеру, так как запрошенный адрес сервера шлюза удалённых рабочих столов не соотвествует имени субъекта сертифката.

    В Сертификате указано следующее:

    Субъект CN = terminal-gateway.domain.local

    Дополнительное имя субъекта IP-адресс = 10.2.2.1 (адресс файрвола)

    4 февраля 2015 г. 6:28
  • Теперь возникает ошибка: Не удалось подключиться к удалённому компьютеру, так как запрошенный адрес сервера шлюза удалённых рабочих столов не соотвествует имени субъекта сертифката.
    А подключаетесь по имени сервера или по ip адресу?

    Также данная ошибка (английский эквивалент):
    This computer can’t connect to the remote computer because the Terminal 
    Services Gateway server address requested and the certificate subject 
    name do not match. 

    присутствует в ранее опубликованной статье "TS Gateway Certificates Part III: Connection Time Issues related to TS Gateway Certificates", в некоторых случаях когда используются внешние днс-сервера и подключения осуществляется по ip-адресу, то данные ip адреса нужно добавлять в альтернативные имена субъектов.

    Best Regards, Andrei ...
    Microsoft Certified Professional

    • Изменено SQxModerator 4 февраля 2015 г. 7:30 добавлено
    4 февраля 2015 г. 7:17
    Модератор
  • Теперь возникает ошибка: Не удалось подключиться к удалённому компьютеру, так как запрошенный адрес сервера шлюза удалённых рабочих столов не соотвествует имени субъекта сертифката.

    А подключаетесь по имени сервера или по ip адресу?

    Также данная ошибка присутствует в ранее опубликованной статье TS Gateway Certificates Part III: Connection Time Issues related to TS Gateway Certificates, в некоторых случаях когда используются внешние днс-сервера и подключения осуществляется по ip-адресу, то данные ip адреса нужно добавлять в альтернативные имена субъектов.

    Best Regards, Andrei ...
    Microsoft Certified Professional

    Подключаюсь по имени сервера. Данные внешнего IP адреса включены в SAN.

    Замечено что это происходит только если подключаться под учётной записью доменного пользователя domain2.local

    Под учётной записью администратора domain2.local ошибки сертификата нет.

    RAP и CAP на шлюзе настроены для группы Domain Users

    4 февраля 2015 г. 7:29