Проблема с шлюзом служб удаленных рабочих столов
Ладно, друзья техники, вот краткое изложение. Я установил Server 2008 r2 Remote Dekstop Services на виртуальную машину в моей сети. Я установил следующие службы ролей RD: Узел сеансов удаленных рабочих столов, Лицензирование, Брокер подключений, Шлюз, Веб-доступ. Когда я все настраивал изначально, сервер шлюза и RDWeb работали, как и должно быть локально. После того, как все работает локально (remoteserver.domainname.local), я захотел протестировать его внешне. Со стороны я не мог запустить все (что означало, что я мог подключиться к rdweb-доступу извне, но когда я попытался запустить приложение, я получил сообщение "не удается подключиться / найти компьютер"). Вот мои настройки для внешнего доступа
- На виртуальной машине установлены все службы ролей служб удаленных рабочих столов, что означает, что она выступает в качестве шлюза, доступа к веб-узлу, узла сеанса, лицензирования и т. Д.
- Я сделал самозаверяющий сертификат на сервере шлюза (gateway.domainname.net - это имя сертификата). Внутренне у меня есть вторичная зона прямого просмотра, называемая domainname.net, с шлюзом записи A, указывающим на локальный IP-адрес сервера шлюза. На нашем общедоступном DNS (domainname.net) у меня есть шлюз записи. Это для доступа к RDWeb извне.
- В IIS у меня есть следующие параметры аутентификации RDWeb: Все отключено, кроме анонимной аутентификации Rpc: Все отключено, кроме основного и Windows RpcWithCert: Все отключено, кроме Windows-аутентификации
- У меня есть необходимая конфигурация веб-доступа в нашем sonicwall tz210 (https и rdp, внешний ip, указывающий на локальный ip сервера rds)
- RAP и CAP имеют правильные группы пользователей и компьютеров, аутентификацию и разрешенные устройства
После всего этого, вот что происходит с внешним доступом. Я могу правильно войти в RDWeb Access (я пробовал поддельную регистрацию, я не могу войти в нее, так что она работает правильно). Я вижу приложения для использования. Я нажимаю на приложение, нажимаю кнопку "Подключиться", открывается окно учетных данных, я ввожу правильные пользовательские кредиты, оно пытается подключиться к серверу шлюза, но затем снова открывается окно кредитов. Я пытался достичь предела неудачных входов в систему, но так и не достиг, хаха.
Поэтому с того же внешнего клиентского компьютера я пытаюсь подключиться к шлюзу через подключение к удаленному рабочему столу. Я установил правильные настройки шлюза в окне RD, попытался подключиться и получил те же результаты, что и при доступе к RDWeb.
Я проверил журналы событий на компьютере со службами удаленных рабочих столов и увидел следующие идентификаторы событий во время внешней попытки входа в систему:
Идентификатор 6037 с сообщением "Программа svchost.exe с назначенным идентификатором процесса 2168 не смогла аутентифицироваться локально с использованием целевого имени host/gateway.domainname.net. Используемое имя цели недопустимо. Имя цели должно ссылаться на одно из имен локального компьютера, например, имя хоста DNS. Попробуйте другое имя цели."
ID 10 RADWebAccess "Веб-доступ к удаленным рабочим столам не удалось получить доступ к gateway.domainname.net, то есть серверу, указанному в качестве запущенной службы RemoteApp и Desktop Connection Management. Убедитесь, что учетная запись компьютера сервера веб-доступа к удаленным рабочим столам является членом Группа безопасности "Компьютеры веб-доступа к службам терминалов на gateway.domainname.net"
ID 4625 "Не удалось войти в аккаунт.
Тема: Идентификатор безопасности: NULL SID Имя учетной записи: - Домен учетной записи: - Идентификатор входа: 0x0
Тип входа: 3
Учетная запись, для которой не удалось выполнить вход: идентификатор безопасности: NULL SID Имя учетной записи: учетная запись администратора Домен: gateway.domainname.net
Информация об отказе: Причина отказа: неизвестное имя пользователя или неверный пароль. Статус: 0xc000006d Sub Статус: 0xc000006a
Информация о процессе: Идентификатор процесса вызывающей стороны: 0x0 Имя процесса вызывающей стороны: -
Сетевая информация: Имя рабочей станции: USER-LAPTOP Исходный сетевой адрес: Внешний IP-порт источника: 63125
Подробная информация об аутентификации: Процесс входа в систему: Пакет аутентификации NtLmSsp: Транзитные службы NTLM: - Имя пакета (только NTLM): - Длина ключа: 0
Это событие генерируется при сбое запроса на вход. Он генерируется на компьютере, к которому была предпринята попытка доступа.
Поля Subject указывают учетную запись в локальной системе, которая запросила вход в систему. Обычно это служба, такая как служба сервера, или локальный процесс, такой как Winlogon.exe или Services.exe.
Поле Тип входа указывает тип входа в систему, который был запрошен. Наиболее распространенными типами являются 2 (интерактивный) и 3 (сетевой).
Поля Информация о процессе указывают, какая учетная запись и процесс в системе запросили вход в систему.
Поля Информация о сети указывают, откуда возник запрос на удаленный вход. Имя рабочей станции не всегда доступно и в некоторых случаях можно оставить пустым.
Поля информации аутентификации предоставляют подробную информацию об этом конкретном запросе на вход. - Транзитные сервисы указывают, какие промежуточные сервисы участвовали в этом запросе на вход. - Имя пакета указывает, какой суб-протокол использовался среди протоколов NTLM."
Я не думаю, что виртуальная машина имеет нулевой SID. SID виртуальной машины и ее физического хоста имеют разные SIDS. Я могу получить доступ к пустой странице для rpc извне, используя имя внешнего шлюза.
Кажется, аутентификация - это проблема. Кроме того, это проблема, что внешнее имя сервера шлюза не совпадает с локальным именем? Внешнее имя (на котором основан сертификат) - gateway.domainname.net, а внутреннее имя - remoteserver.domainname.local. Это единственная вещь, о которой я могу думать, это проблема, но внешнее имя должно отличаться от местного права? Внутренне я пингую gateway.domainname.net, и он дает мне правильный локальный IP-адрес сервера. Так вот, в AD нет фактического имени компьютера, но я не знаю, как мне этого добиться?
Я надеюсь, что я был ясен.... любая помощь будет оценена. Я думаю, что я близок к достижению этого.:)
1 ответ
Одна из возможных причин проблемы:
Internally, I have a secondary forward-lookup zone called domainname.net with an A record gateway pointing to the local IP of the gateway server.
Это. Не делай этого. Потерять эту запись DNS. Вы не должны смешивать внутренние и внешние DNS-зоны, а RDS Gateway предназначен для работы с этим правилом. В клиенте удаленного рабочего стола установите для сервера шлюза значение domainname.net, затем на хосте, к которому вы подключаетесь, используйте внутреннее DNS-имя сервера.
Как в сторону,
I have the necessary web access config in our sonicwall tz210 (https and rdp, external ip pointing to local ip of rds server)
Вам вовсе не нужен открытый порт RDP (TCP 3389). Весь трафик превышает 443, если вы используете шлюз RDS.