Хорошо, ребята, технари, вот краткое изложение. Я установил Server 2008 r2 Remote Dekstop Services на виртуальную машину в моей сети. Я установил следующие службы ролей удаленных рабочих столов: узел сеанса удаленных рабочих столов, лицензирование, посредник подключений, шлюз, веб-доступ. Когда я все настраивал изначально, сервер шлюза и RDWeb работали как надо локально. После того, как все заработало локально (remoteserver.domainname.local), я захотел протестировать вещи извне. Со стороны я не мог запустить что-либо (то есть я мог подключиться к доступу через rdweb извне, но когда я пытался запустить приложение, я получал сообщение «не могу подключиться / найти компьютер»). Вот моя настройка для внешнего доступа
После всего этого вот что происходит с внешним доступом. Я могу правильно войти в RDWeb Access (я пробовал поддельный вход, я не могу войти в него, поэтому он работает правильно). Я вижу приложения для использования. Я нажимаю на приложение, нажимаю кнопку подключения, открывается окно учетных данных, я ввожу правильные пользовательские кредиты, оно пытается подключиться к серверу шлюза, но затем снова появляется окно кредитов. Я пытался достичь лимита неудачных попыток входа в систему, но так и не достиг, ха-ха.
Итак, с той же внешней клиентской машины я пытаюсь подключиться к шлюзу через подключение к удаленному рабочему столу. Я ввел правильные настройки шлюза в окно RD, пытаюсь подключиться и получаю те же результаты, что и при доступе к RDWeb.
Я проверил журналы событий на компьютере со службами RD и увидел следующие идентификаторы событий примерно в то время, когда я пытался войти в систему извне:
ID 6037 с сообщением «Программа svchost.exe с назначенным идентификатором процесса 2168 не смогла аутентифицироваться локально с использованием целевого имени host / gateway.domainname.net. Используемое целевое имя недействительно. Целевое имя должно ссылаться на одно из имен локального компьютера, например, имя хоста DNS. Попробуйте другое целевое имя. "
ID 10 RADWebAccess «Веб-доступ к удаленным рабочим столам не смог получить доступ к gateway.domainname.net, который является сервером, на котором запущена служба управления подключениями RemoteApp и рабочего стола. Убедитесь, что учетная запись компьютера сервера веб-доступа к удаленным рабочим столам является членом Группа безопасности TS Web Access Computers на gateway.domainname.net "
ID 4625 «Не удалось войти в учетную запись.
Тема: Идентификатор безопасности: NULL SID Имя учетной записи: - Домен учетной записи: - Идентификатор входа: 0x0
Тип входа: 3
Учетная запись, для которой не удалось выполнить вход: идентификатор безопасности: NULL SID Имя учетной записи: домен учетной записи администратора: gateway.domainname.net
Информация о сбое: Причина сбоя: Неизвестное имя пользователя или неверный пароль. Статус: 0xc000006d Дополнительный статус: 0xc000006a
Информация о процессе: Идентификатор процесса вызывающего абонента: 0x0 Имя процесса вызывающего абонента: -
Сетевая информация: Имя рабочей станции: USER-LAPTOP Сетевой адрес источника: Внешний IP-порт источника: 63125
Подробная информация об аутентификации: Процесс входа в систему: Пакет аутентификации NtLmSsp: Транзитные службы NTLM: - Имя пакета (только NTLM): - Длина ключа: 0
Это событие создается при сбое запроса входа в систему. Он создается на компьютере, на котором была предпринята попытка доступа.
В полях «Тема» указывается учетная запись в локальной системе, которая запросила вход. Чаще всего это служба, такая как служба сервера, или локальный процесс, например Winlogon.exe или Services.exe.
Поле «Тип входа» указывает тип запрошенного входа в систему. Наиболее распространены типы 2 (интерактивный) и 3 (сетевой).
В полях «Информация о процессе» указано, какая учетная запись и процесс в системе запросили вход.
Поля информации о сети указывают, откуда исходит запрос удаленного входа в систему. Имя рабочей станции не всегда доступно и в некоторых случаях может быть оставлено пустым.
Поля информации об аутентификации предоставляют подробную информацию об этом конкретном запросе на вход. - Транзитные службы указывают, какие промежуточные службы участвовали в этом запросе на вход. - Название пакета указывает, какой подпротокол использовался среди протоколов NTLM ".
Я не думаю, что виртуальная машина имеет нулевой SID. SID виртуальной машины и ее физического хоста имеют разные SID. Я могу получить доступ к пустой странице для rpc извне, используя имя внешнего шлюза.
Кажется, проблема с аутентификацией. Кроме того, проблема в том, что внешнее имя сервера шлюза не совпадает с локальным именем? Внешнее имя (на котором основан сертификат) - gateway.domainname.net, а внутреннее имя - remoteserver.domainname.local. Это единственное, о чем я могу думать, что могло бы стать проблемой, но внешнее имя должно отличаться от локального, верно? Внутренне я пингую gateway.domainname.net, и он дает мне правильный локальный IP-адрес сервера. В AD нет настоящего имени компьютера, но я не знаю, как мне этого добиться?
Надеюсь, я был ясен .... любая помощь будет оценена. Думаю, я близок к этому. :)
Одна из возможных причин проблемы:
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 предназначен для работы с этим правилом. В клиенте удаленного рабочего стола установите сервер шлюза на 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). Если вы используете шлюз RDS, весь трафик превышает 443.