Настройки безопасности этого компьютера не разрешают доступ к источнику данных в другом домене

Обновлено: 21.11.2024

Сеансы удаленного рабочего стола работают по зашифрованному каналу, поэтому никто не может просматривать ваш сеанс, прослушивая сеть. Однако в методе, используемом для шифрования сеансов в более ранних версиях RDP, есть уязвимость. Эта уязвимость может сделать возможным несанкционированный доступ к вашему сеансу с помощью атаки «человек посередине».

Удаленный рабочий стол можно защитить с помощью SSL/TLS в Windows Vista, Windows 7, Windows 8, Windows 10 и Windows Server 2003/2008/2012/2016. *Некоторые перечисленные системы больше не поддерживаются Microsoft и поэтому не соответствуют стандартам безопасности Campus. Если неподдерживаемые системы все еще используются, требуется исключение безопасности.

Хотя удаленный рабочий стол более безопасен, чем инструменты удаленного администрирования, такие как VNC, которые не шифруют весь сеанс, всякий раз, когда администратору предоставляется удаленный доступ к системе, возникают риски. Следующие советы помогут защитить удаленный доступ к рабочим столам и серверам, которые вы поддерживаете.

Основные советы по безопасности для удаленного рабочего стола

1. Используйте надежные пароли

Надежные пароли для любых учетных записей с доступом к удаленному рабочему столу следует рассматривать как обязательный шаг перед включением удаленного рабочего стола. Советы см. в руководстве по сложности пароля кампуса.

2. Используйте двухфакторную аутентификацию

Отделы должны рассмотреть возможность использования двухфакторной аутентификации. Эта тема выходит за рамки данной статьи, но шлюзы удаленных рабочих столов можно настроить для интеграции с экземпляром Campus DUO. Другими доступными опциями, не поддерживаемыми кампусом, будет простой механизм контроля аутентификации с помощью смарт-карт на основе двухфакторных сертификатов. Этот подход использует сам узел удаленного рабочего стола в сочетании с YubiKey и RSA в качестве примеров.

3. Обновите программное обеспечение

Одним из преимуществ использования удаленного рабочего стола по сравнению со сторонними инструментами удаленного администрирования является то, что компоненты автоматически обновляются с использованием последних исправлений безопасности в рамках стандартного цикла исправлений Microsoft. Убедитесь, что вы используете последние версии как клиентского, так и серверного программного обеспечения, включив и проведя аудит автоматических обновлений Microsoft. Если вы используете клиенты удаленного рабочего стола на других платформах, убедитесь, что они по-прежнему поддерживаются и у вас установлены последние версии. Старые версии могут не поддерживать высокий уровень шифрования и иметь другие недостатки безопасности.

4. Ограничить доступ с помощью брандмауэров

Используйте брандмауэры (как программные, так и аппаратные, если они доступны), чтобы ограничить доступ к прослушивающим портам удаленного рабочего стола (по умолчанию TCP 3389). Использование шлюза RDP настоятельно рекомендуется для ограничения доступа RDP к рабочим столам и серверам (см. обсуждение ниже). В качестве альтернативы для поддержки подключения за пределами кампуса вы можете использовать программное обеспечение кампусной VPN, чтобы получить IP-адрес кампуса и добавить пул сетевых адресов кампусной VPN в правило исключения брандмауэра RDP. Посетите нашу страницу для получения дополнительной информации о VPN-сервисе кампуса.

5. Включить аутентификацию на уровне сети

Windows 10, Windows Server 2012 R2/2016/2019 также по умолчанию обеспечивают проверку подлинности на уровне сети (NLA). Лучше оставить это на месте, так как NLA обеспечивает дополнительный уровень аутентификации до установления соединения. Серверы удаленных рабочих столов следует настраивать так, чтобы разрешать подключения без NLA, только если вы используете клиенты удаленных рабочих столов на других платформах, которые его не поддерживают.

NLA должен быть включен по умолчанию в Windows 10, Windows Server 2012 R2/2016/2019.

Для проверки можно посмотреть параметр групповой политики Требовать аутентификацию пользователя для удаленных подключений с помощью аутентификации на уровне сети, который находится в папке Компьютер\Политики\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Безопасность. Этот параметр групповой политики должен быть включен на сервере с ролью узла сеансов удаленных рабочих столов.

6. Ограничьте количество пользователей, которые могут входить в систему с помощью удаленного рабочего стола

По умолчанию все администраторы могут входить в удаленный рабочий стол. Если на вашем компьютере есть несколько учетных записей администратора, вы должны ограничить удаленный доступ только теми учетными записями, которым это необходимо. Если удаленный рабочий стол не используется для системного администрирования, удалите весь административный доступ через RDP и разрешите только учетные записи пользователей, которым требуется служба RDP. Для отделов, которые управляют многими машинами удаленно, удалите учетную запись локального администратора из доступа RDP по адресу и вместо этого добавьте техническую группу.

Нажмите Пуск-->Программы-->Администрирование-->Локальная политика безопасности

В разделе «Локальные политики» -> «Назначение прав пользователя» выберите «Разрешить вход через службы терминалов». Или «Разрешить вход через службы удаленных рабочих столов»

Удалите группу «Администраторы» и оставьте группу «Пользователи удаленного рабочего стола».

Используйте панель управления системой, чтобы добавить пользователей в группу пользователей удаленного рабочего стола.

Типичная операционная система MS по умолчанию имеет следующие настройки, как показано в локальной политике безопасности:

Проблема в том, что «Администраторы» здесь по умолчанию, а ваша учетная запись «Локальный администратор» находится в группе администраторов. Несмотря на то, что рекомендуется соглашение о паролях, чтобы избежать идентичных паролей локального администратора на локальном компьютере и жестко контролировать доступ к этим паролям или соглашениям, использование учетной записи локального администратора для удаленной работы на компьютере не позволяет должным образом регистрировать и идентифицировать пользователя, использующего систему. Лучше всего переопределить локальную политику безопасности с помощью параметра групповой политики.

Для управления доступом к системам также полезно использовать «Группы с ограниченным доступом» с помощью групповой политики.

Если вы используете параметр «Группа с ограниченным доступом», чтобы поместить свою группу, например, «CAMPUS\LAW-TECHIES» в «Администраторы» и «Пользователи удаленного рабочего стола», ваши технические специалисты по-прежнему будут иметь удаленный административный доступ, но с помощью шагов выше вы удалили проблемную «учетную запись локального администратора», имеющую доступ по RDP. В дальнейшем при добавлении новых машин в OU под объектом групповой политики ваши настройки будут правильными.

7. Установите политику блокировки учетной записи

Настроив свой компьютер на блокировку учетной записи для определенного количества неверных ответов, вы поможете хакерам не получить доступ к вашей системе с помощью инструментов автоматического подбора пароля (это называется атакой методом грубой силы). Чтобы установить политику блокировки учетной записи:

Выберите "Пуск" --> "Программы" --> "Администрирование" --> "Локальная политика безопасности".
В разделе «Политика учетной записи» -> «Политика блокировки учетной записи» задайте значения для всех трех параметров. Три недействительные попытки с трехминутной блокировкой являются разумным выбором.

Ограничение доступа к RDP с помощью брандмауэра Windows

Если у вас есть компьютер, управляемый кампусом:

Обратитесь за помощью в ИТ-службу поддержки клиентов или в ИТ-поддержку вашего отдела.

Если у вас есть персональный компьютер и права администратора:

Следуйте инструкциям в этой статье, чтобы обновить брандмауэр Windows, чтобы только авторизованные хосты и сети могли получить доступ к вашей системе через удаленный рабочий стол (RDP).

Настройки > Обновление и безопасность > Безопасность Windows > Брандмауэр и защита сети > Дополнительные параметры > Правила для входящих подключений > Удаленный рабочий стол — режим пользователя (TCP-In) > Свойства > Область действия > Удаленный IP-адрес > Добавить > Этот IP-адрес или подсеть< /p>

Безопасность Windows > Брандмауэр и защита сети

Правила для входящих подключений > Удаленный рабочий стол — Режим пользователя (TCP-входящий) > Свойства

В поле Этот IP-адрес или подсеть добавьте только те IP-адреса и сетевые подсети, которым должно быть разрешено подключение к службе удаленного рабочего стола (RDP) вашего компьютера. Некоторые распространенные примеры IP-адресов и подсетей кампуса перечислены в разделе ниже.

IP-адреса и подсети кампуса

Исходя из ваших потребностей, выбирайте только авторизованные IP-адреса и подсети кампуса для подключения к службе RDP вашего компьютера. Network Operations & Services поддерживает исходный список UC Berkeley Campus Networks, но некоторые распространенные примеры приведены ниже для справки.

IST RD Gateway
Чтобы получить доступ к вашей системе через RDP напрямую из Интернета, используйте Campus Remote Desktop Gateway. Шлюз удаленных рабочих столов позволит вам использовать ваш идентификатор CalNet с push-уведомлениями Duo для подключения. Вы можете авторизовать шлюз удаленных рабочих столов, добавив следующую подсеть в правило брандмауэра:

Кампусные VPN-сети удаленного доступа (bSecure Remote Access Services with GlobalProtect)
Чтобы получить доступ к вашей системе через RDP через кампусную VPN, добавьте одну или несколько следующих VPN-сетей в правило брандмауэра:< /p>

Раздельные туннельные клиентские сети
- 10.136.128.0/18
- 136.152.16.0/20
- 136.152.210.0/23
Сети кампуса (на месте)

Чтобы получить доступ к вашей системе через RDP, находясь в кампусе, добавьте соответствующие беспроводные или проводные сети кампуса в правило брандмауэра:
- AirBears2 и беспроводные сети eduroam
  - 10.142.0.0/16, 136.152.28.0/22, 136.152.36.0/22, 136.152.142.0/24, 136.152.145.0/24, 136.152.148.0/22, 2607:f140:400::/48
  - 128.32.0.0/16, 136.152.0.0/16, 136.152.0.0/16, 192.31.105.0/24
  Эта работа находится под лицензией Creative Commons Attribution-NonCommercial 4.0 International License.
  
  Этот форум закрыт. Спасибо за ваш вклад.
  
  Вопрос:
  
  Вопрос
  
  У меня есть пользователь (под управлением Windows 7), который сталкивается с проблемой "Настройки безопасности на этом компьютере запрещают доступ к источнику данных в другом домене" в моей программе HTA. Только некоторые пользователи сталкиваются с проблемой. Компьютеры, которые я мог найти с Windows 7, Windows 8, Windows 10, все в порядке. Чтобы вызвать помощь, мне нужно найти способ воспроизвести проблему на 100%, и я, наконец, воспроизвел ту же проблему на чистой установленной Windows XP на виртуальной машине VMware, как показано ниже,
  
  На приведенном выше рисунке видно, что один и тот же код отлично работает с cscript.exe (WSH), но всегда дает сбой с HTA в Windows XP.
  
  Я потратил много времени на гугление и пробу настроек "Инструментов администратора" Windows, так и не смог исправить это на плохом компьютере или воспроизвести на хорошем компьютере.
  
  Я упростил код до 3.hta и 2.js.
  
  Запуск 3.hta на плохой windows 7 воспроизвел проблему, на любой Windows Xp тоже.
  
  Выполнить 2.js (командная строка "cscript.exe 2.js") можно на всех компьютерах.
  
  Но 3.hta и 2.js логически абсолютно одинаковы!!
  
  помогите помогите спасибо спасибо
  
  вар аду;
  ado = новый ActiveXObject("ADODB.Stream");
  переменные данные;
  ado.CharSet = "utf-8";
  ado.Open();
  ado.LoadFromFile("2.js");
  данные = ado.ReadText();
  ado.Close();
  WScript.echo(данные);
  
  caption="yes"
  maximizebutton="no"
  minimizebutton="no"
  sysmenu= "да"
  BORDERSTYLE="сложный"
  BORDER="толстый"
  />
  HTA — Отладка
  
  HTA - Отладка, попробуйте прочитать мой собственный исходный код "3.hta"
  
  Все ответы
  
  Это помогло мне на XP:
  
  Установите значение 0 (ноль):
  
  Извините за столь поздний ответ. Но я только сейчас столкнулся с этим вопросом.
  
  Основная проблема заключается в том, что в статье Microsoft о HTML-приложениях упущены некоторые важные моменты, касающиеся этого.
  
  Файлы HTA выполняются за пределами обычных настроек безопасности IE, касающихся только двух основных параметров: «Инициализировать и создавать сценарии для элементов ActiveX, помеченных как небезопасные для сценариев». И междоменные ссылки «Iframe». Обратите внимание: когда я говорю, что ссылка — это *не* сценарий. Даже в файлах HTA вы не можете внедрить код скрипта в iframe, принадлежащий другому домену. Однако вы можете ссылаться на файлы, расположенные на локальном диске пользователя, даже если HTA выполняется из общего сетевого ресурса или HTTP-адреса. Кроме того, файлы HTA будут запускать ActiveX и код сценария, даже если они выполняются в контексте зоны «Ограниченные сайты» IE, которая по умолчанию никогда не разрешает такие действия. *НО* он унаследует большинство других настроек безопасности, таких как атрибут «Данные объекта» и «Доступ к источникам данных через домены». Судя по тому, что я видел на картинке, файл HTA загружается из Интернета, что заставляет большинство веб-браузеров «принуждать» файл в том же контексте веб-сайта, с которого он был получен, что в 99,99% случаев Интернет Зона. Это делается путем добавления простого потока данных NTFS в загруженный файл с именем «Zone.Identifier». Чтобы убедиться, что HTA будет работать в контексте зоны локального компьютера, который по умолчанию разрешает доступ к источникам данных через домены, вы можете попробовать использовать сценарии и ActiveX для удаления потока данных NTFS, но, позвольте мне сказать вам, это немного глючит. Таким образом, лучшим решением может быть предложение вашим пользователям щелкнуть правой кнопкой мыши загруженный файл HTA и выбрать «свойства» в меню. Затем в окне со свойствами файла нажмите кнопку «Разблокировать», затем нажмите кнопку «ОК». Вот и все, теперь файл HTA будет запускаться в контексте зоны локального компьютера и больше не будет (по умолчанию) отображать эту ошибку. Решение, предложенное нашим другом, которое требует редактирования реестра, допустимо, но не рекомендуется, особенно в корпоративной среде, потому что изменение настроек безопасности (в любой зоне IE) может привести к серьезным проблемам с безопасностью, и администратору это не понравится. вообще.
  
  В этой технической заметке объясняется, как настроить доступ к базам данных Microsoft® SQL Server, используемым IBM® Rational® ClearQuest®, когда сервер находится в отдельном домене и пользователи не могут подключиться.
  
  Симптом
  
  Если базы данных ClearQuest, размещенные на SQL Server, находятся на сервере, который находится в другом домене Microsoft Windows, вы можете получить ошибки при попытке создать базы данных или подключиться к ним.
  
  Причина
  
  Это происходит, когда SQL Server настроен на использование только "именованных каналов" в качестве сетевого протокола. Использование именованных каналов требует, чтобы SQL Server мог обращаться к файлам от имени вызывающего идентификатора пользователя, что, в свою очередь, требует, чтобы запрашивающий идентификатор пользователя был «известен» в домене SQL Server. Если ваш идентификатор пользователя определен в одном домене, а сервер — в другом, и отношения доверия между доменом не существуют, то запрашивающий идентификатор пользователя не является «известным». В этот момент аутентификация завершается ошибкой.
  
  Решение проблемы
  
  Вот некоторые известные обходные пути:
  
  Есть несколько способов обойти эту проблему:
  
  Настроить доступ пользователей к тому же домену, что и SQL Server
  
  Одним из способов обхода является создание идентификатора пользователя в домене Microsoft Windows сервера с тем же именем пользователя и паролем, что и у запрашивающего идентификатора пользователя. Затем, когда SQL Server использует именованные каналы для аутентификации, он завершается успешно.
  
  Хотя этот подход прост в реализации, он не является хорошим решением для больших сетей с большим количеством пользователей, поскольку требует, чтобы все действия по обслуживанию идентификаторов пользователей и паролей выполнялись дважды, по одному разу в каждом домене Microsoft Windows.
  
  Настроить доверие домена
  
  Еще одно решение — настроить отношение "доверие к домену", чтобы домен, в котором SQL Server "доверяет" домену, в котором определен запрашивающий пользователь. Доверительное отношение фактически делает видимыми всех пользователей, определенных в "доверенном" домене. и действителен в «доверяющем» домене (домен SQL Server).
  
  Этот подход также прост в применении (и не имеет административных последствий, таких как обходной путь с повторяющимся идентификатором пользователя выше), он может не соответствовать требованиям безопасности вашей компании.
  
  Настройка соединения SQL Server для TCP/IP
  
  Если предыдущие решения невозможны или не разрешены политикой безопасности вашей компании, то именованные каналы не могут быть единственным сетевым протоколом для SQL Server. Настройте SQL Server для использования TCP/IP.
  
  На SQL Server настройте сервер для поддержки TCP/IP вместо именованных каналов или в дополнение к ним.
  1. Вызовите «Сетевую утилиту сервера» в меню «Пуск» > «Программы» > Microsoft SQL Server 7.0.
  2. На вкладке "Общие", если TCP/IP еще не отображается, нажмите "Добавить".
  3. Установите для сетевой библиотеки значение TCP/IP.
  4. Убедитесь, что номер порта – 1433. Кроме того, вы можете выбрать другой порт и запомнить его для использования с процедурой на стороне клиента, описанной ниже.

Настройки безопасности этого компьютера не разрешают доступ к источнику данных в другом домене

Основные советы по безопасности для удаленного рабочего стола

1. Используйте надежные пароли

2. Используйте двухфакторную аутентификацию

3. Обновите программное обеспечение

4. Ограничить доступ с помощью брандмауэров

5. Включить аутентификацию на уровне сети

6. Ограничьте количество пользователей, которые могут входить в систему с помощью удаленного рабочего стола

7. Установите политику блокировки учетной записи

Рекомендации по обеспечению дополнительной безопасности

1. Не разрешайте прямой доступ RDP к клиентам или серверам за пределами кампуса.

2. Использовать шлюзы RDP (лучший вариант)

3. Измените порт прослушивания для удаленного рабочего стола

4. Туннельное подключение к удаленному рабочему столу через IPSec или SSH

5.Используйте существующие инструменты управления для регистрации и настройки RDP

Ограничение доступа к RDP с помощью брандмауэра Windows

IP-адреса и подсети кампуса

Вопрос:

Вопрос

HTA - Отладка, попробуйте прочитать мой собственный исходный код "3.hta"

Все ответы

Симптом

Причина

Решение проблемы

Управление источниками данных

Ограничения