Anydesk вход без подтверждения: настроить постоянное подключение

1 Настройка виртуальной машины

Устанавливаем на виртуальный сервер ОС Windows Server 2022 R2 Standard EN и все последние обновления Windows Update.

Виртуальный сервер имеет два сетевых контроллера. В ОС условно назовём относящиеся к этим контроллерам сетевые интерфейсы – LAN и WAN. Интерфейс LAN будет смотреть в локальную сеть (либо в DMZ) и настроен следующим образом:

Шлюз по умолчанию на интерфейсе LAN не указываем.

Интерфейс WAN будет направлен в Интернет. В свойствах интерфейса желательно выключить все компоненты кроме TCP/IPv4. Шлюз по умолчанию задан. 

Чтобы при такой конфигурации сетевых интерфейсов сервер был доступен из локальной сети, создадим в системе постоянный маршрут в локальную сеть через интерфейс LAN:

route -p ADD 10.0.0.0 MASK 255.0.0.0 10.160.20.1
route PRINT

2. Установка роли Remote Access

Открываем оснастку Server Manager, выбираем область настроек Local Server, в верхнем меню выбираем Manage > Add Roles and Features. В мастере добавления ролей выбираем тип установки на основе ролей – Role-based or feature-based installation

Далее выбираем сервер из пула серверов…

На шаге выбора ролей включаем роль Remote Access

Шаг Features пропускаем без внесения изменений.На шаге выбора служб включаемой роли выберем службу DirectAccess and VPN (RAS)

При этом откроется окно добавления дополнительных компонент связанных с выбранной службой. Согласимся с их установкой нажав Add Features

Роль Web Server Role (IIS) будет при этом добавлена в мастер добавления ролей. Соответствующий появившийся шаг мастера  Web Server Role (IIS) и зависимые опции Role Services пропускаем с предложенными по умолчанию настройками и запускаем процесс установки, по окончании которого будет доступна ссылка на мастер первоначальной настройки служб Remote Access – Open the Getting Started Wizard

Можно вызвать мастер настройки RAS щёлкнув по соответствующей ссылке здесь, либо позже из оснастки Server Manager:

Так как настройка DirectAccess в контексте нашей задачи не нужна, в окне мастера выбираем вариант конфигурирования только VPN – Deploy VPN only

. Создание NLB-кластера из двух VPN-серверов

Отправной документ для построения кластера здесь: Deploy Remote Access in a ClusterПланирование описано в документе Plan a Remote Access Cluster DeploymentКонфигурирование кластера описано в документе Configure a Remote Access Cluster

***

Первым делом обратим внимание на то, что в свойствах виртуальных машин Hyper-V, в которых работают наши VPN-серверы, которые мы хотим сделать членами NLB кластера, для сетевого адаптера WAN необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses). Именно этот сетевой адаптер мы будем делать членом NLB-кластера.

***

Затем создаём во внешней зоне DNS статическую А-запись для будущего NLB кластера:

p align=”center”>***Далее, с помощью PowerShell установим на оба VPN-сервера исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

p align=”center”>***

После добавления роли NLB в Windows Firewall добавляется ряд правил связанных с этой ролью. Нам нужно будет откорректировать эти правила, в частности свести к минимуму возможность контакта к интерфейсам управления NLB из Интернет, отключить правила для IPv6, если этот протокол не используется, ограничить правила меж-узлового обмена и т.п. В конечном итоге, из включённых и настроенных правил, касающихся NLB, у меня получилась такая картина на первом VPN-сервере:

На втором VPN-сервере:

p align=”center”>***

Теперь приступим к процессу создания NLB-кластера.

На первом сервере RAS (KOM-AD01-VPN01) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот, который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее зарегистрировали А-запись во внешней зоне DNS.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. В нашем примере выбран режим одноадресной рассылки – Unicast.

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

Отдельное замечание по допустимым режимам фильтрации (Filtering Mode), касающееся построения NLB для VPN можно найти в документе Create a new Network Load Balancing Port Rule:

When using NLB to load balance virtual private network (VPN) traffic (such as PPTP/GRE and IPSEC/L2TP), you must configure the port rules that govern the ports handling the VPN traffic (TCP port 1723 for PPTP and UDP port 500 for IPSEC) to use either Single or Network affinity.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 1723 – Routing and Remote Access (PPTP-In);UDP 1701 – Routing and Remote Access (L2TP-In);UDP 500 – Routing and Remote Access (Allows IKE traffic to the VPN server);UDP 4500 – Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.);

Все необходимые параметры кластера заданы, создаем его по нажатию кнопки Finish и после первоначальной инициализации, если в конфигурации не допущены ошибки, NLB кластер запуститься в конфигурации с одним узлом

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго сервера в кластер.

Вводим имя второго VPN-сервера, подключаемся к нему кнопкой Connect и после появления информации о сетевых интерфейсах сервера выбираем WAN-интерфейс, который хотим включить в NLB кластер.

Все прочие настройки при добавлении узла кластера можно оставить по умолчанию.

После добавления второго узла мы получим работоспособный Windows NLB кластер

Проверка подключения VPN-клиента по протоколу PPTP

На данном этапе первоначальная настройка первого VPN-сервера выполнена и он уже готов принимать клиентские подключения. Поэтому теперь можно проверить подключение по протоколу PPTP. Согласно описанной нами конфигурации, сделать это можно в том числе и с клиентского компьютера внутри локальной сети.

Пошаговое описание процесса создания VPN-подключения на клиенте под управлением Windows можно найти в п.12 данной статьи. После того как на клиентском компьютере VPN-подключение создано, откроем его свойства и на закладке “Безопасность” выберем тип VPN – PPTP

На закладке “Сеть” выберем протокол TCP/IPv4 и откроем его “Свойства”

В окне свойств нажмём кнопку “Дополнительно” и отключим опцию “Использовать основной шлюз в удалённой сети”. Это нужно сделать для того, чтобы при подключении с клиента локальной сети у нас не возникло проблем с уже работающими сетевыми приложениями на клиентском компьютере во время проведения теста подключения.

Сохраним изменения и попробуем выполнить подключение к VPN-серверу.

Если проверка подключения из локальной сети прошла успешно, можно протестировать подключение с внешнего VPN-клиента из Интернет также по протоколу PPTP. Таким образом мы убедимся в том, что правила Windows Firewall на VPN-сервере настроены правильно и служба RAS успешно выполняет подключение VPN-клиентов, выдаёт им при этом правильные настройки IP, и корректно маршрутизирует трафик от VPN-клиента в локальную сеть и обратно.

2. Создание дополнительной сетевой политики NPS для PPTP-подключений

Созданная ранее сетевая политика будет использоваться как основная политика “по умолчанию” для всех подключающихся VPN клиентов. Как уже было сказано ранее, наша конфигурация подразумевает то, что VPN-клиенты в качестве основного протокола будут использовать L2TP/Ipsec, а для его первоначальной настройки каждому клиенту хотя бы один раз потребуется кратковременная PPTP-сессия.

PPTP-сессия в нашем случае нужна для того, чтобы подключиться клиенту к одному единственному ресурсу локальной сети – Центру сертификации для получения сертификата для клиентского компьютера. Так как протокол PPTP является более устаревшим и менее защищённым чем L2TP/Ipsec, нам нужно на сервере NPS (RADIUS) создать ещё одну сетевую политику, с помощью которой будут заданы жёсткие ограничения для PPTP соединений.

То есть, в рамках нашей задачи, любая PPTP-сессия будет разрешать трафик исключительно до нескольких хостов локальной сети (Сервер ЦС и DNS-серверы) и будет при этом ограничена по времени, которого достаточно для того, чтобы сформировать запрос на получение сертификата в ЦС и получение автоматически выданного цифрового сертификата клиентского компьютера.

3. Добавление информации о VPN-сервере на сервер RADIUS

Политики сетевого доступа для VPN-клиентов на сервере NPS созданы, но для того, чтобы VPN-серверы могли обращаться к серверам RADIUS как поставщику аутентификации и обрабатываться созданными политиками, нам необходимо прописать эти VPN-серверы в качестве клиентов RADUIS.

В окне добавления нового клиента RADIUS на закладке Settings укажем полное доменное имя нашего VPN-сервера (тут же проверим, что оно успешно разрешается в IP с помощью кнопки Verify) и в ручную укажем пароль Shared secret для установления безопасного соединения между клиентом и сервером RADIUS. Запомним этот пароль, так как он понадобиться нам на следующем этапе настройки VPN-сервера.

На закладке Advanced оставим настройки предложенные по умолчанию.

Аналогичный образом создадим на RADIUS сервере запись о втором VPN-сервере…

Если у нас более одного сервера RADIUS, дублируем информацию о клиентах RADIUS (VPN-серверах) с идентичными настройками на дополнительных серверах.

Привязка VPN-сервера к серверам RADIUS

Теперь нам нужно выполнить настройку наших VPN-серверов для использования RADIUS аутентификации выполнив привязку к ранее настроенным RADIUS-серверам. Возвращаемся на VPN-сервер в консоль Routing and Remote Access, снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties.

На закладке Security меняем поставщиков Authentication provider и Accounting provider на RADIUS Authentication и RADIUS Accounting соответственно. Чтобы задать параметры соединения с серверами RADIUS нажимаем кнопку Configure

Добавляем информацию о серверах RADIUS. Как минимум, указываем для каждого из них имя Server name и Shared secret заданным нами ранее в п.4.3

Закрываем все окна сохранив изменения.

Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec

Меняем настройки VPN-подключения на клиентском компьютере на использование протокола L2TP/Ipsec и проверяем подключение из Интернет.

В случае проблем с подключением, изучаем event-логи на VPN-сервере, а также на сервере RADIUS, так как теперь все события связанные с процедурами аутентификации и авторизации фиксируются именно там.

Если подключение к первому настроенному VPN-серверу по протоколу l2TP/Ipsec прошло успешно, то можно приступить к следующему этапу расширения конфигурации. 

Lan manager (lm)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

Nt lan manager (ntlm)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер – к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM.

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Получив эти данные, контроллер домена извлекает хэш указанного пользователя и вычисляет на основе запроса сервера проверочную комбинацию, которую сравнивает с полученным NTLM-ответом, при совпадении серверу посылается сообщение, что аутентификация прошла успешно.

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети.

Ntlmv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число – запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Royal ts (shareware)

Когда-то была такая программулина — mRemote. Не знаю, что там произошло, но проект mRemote был закрыт, а разработчики взяли и создали другой проект — Royal TS. На сайте ты найдешь версии для Windows, OS X и iOS (можно запускать с iPhone и iPad).

В Royal TS перед созданием подключения нужно создать документ, то есть одно подключение = один документ. Документы Royal TS весьма удобная штука, их можно передавать как обычные файлы, например другому админу. Он сможет открыть такой документ и сразу подключиться к удаленному компу без необходимости создавать соединение вручную.

У shareware-версии есть ограничение на число одновременно открытых документов — десять. Как по мне, то этого вполне достаточно для некоммерческого использования программы, поэтому на практике ты даже не заметишь, что тебе чего-то не хватает (если, конечно, ты не администрируешь удаленно огромную сеть компов).

Ultravnc/realvnc

VNC (Virtual Network Computing) — система удаленного доступа к рабочему столу компьютера, использующая протокол RFB (Remote FrameBuffer). Ранее было показано, как организовать VNC-сервер в Linux, в Windows такой сервер можно создать средствами программ UltraVNCили RealVNC.

Программа UltraVNC подобна RealVNC, но обладает дополнительными возможностями вроде шифрования соединения между клиентом и сервером, модуля Java Viewer (доступ к удаленному ПК через браузер с поддержкой Java) и других. Хотя у RealVNC есть плагин VNC Viewer для Google Chrome, поэтому нет необходимости в Java Viewer. Как уже было отмечено, программы во многом подобны, поэтому в этой статье мы рассмотрим только UltraVNC.

При установке UltraVNC есть возможность установить как VNC-сервер, так и VNC-клиент. На твой компьютер, если к нему не нужен удаленный доступ, VNC-сервер можно не устанавливать. При установке VNC-сервера будет возможность настроить его для запуска в виде системной службы, но для этого нужны права админа.

Для подключения к VNC-серверу используется программа UltraVNC Viewer. Программа универсальна, и ты можешь использовать ее для подключения к любому VNC-серверу, а не только к тому, на котором запущен UltraVNC Server. Аналогично к серверу, созданному программой UltraVNC Server, можно подключиться программой RoyalTS или любым другим VNC-клиентом.

Пару слов о том, как это все работает. Сначала запускаем программу UltraVNC Edit Settings и на вкладке Security задаем пароль для доступа к VNC-серверу, затем нужно запустить программу UltraVNC Server. После на другом компьютере запускаем UltraVNC Viewer (рис. 14) и вводим IP компа, на котором установлен VNC-сервер, и нажимаем кнопку Connect.

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

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

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation).

Возможен ли в anydesk вход без подтверждения

В бесплатной для некоммерческого использования версии АниДеск возможен так называемый неконтролируемый доступ – подключение к клиенту без подтверждения. После включения опции и установки пароля соединение между устройствами происходит без запроса на удалённое управление. Для реализации функции программу необходимо установить на оба устройства (компьютера), а не просто запустить.

1. В главном окне найдите соответствующую кнопку.
   
2. Укажите параметры инсталляции, затем нажмите «Принять и установить».
3. Запустится установленная программа. Она добавляется в автоматический запуск операционной системы – будет постоянно запускаться одновременно с Windows. Подробно, как удалить AnyDesk из автозагрузки, читайте отдельно.

Настройка неконтролируемого доступа для windows

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

1. Откройте настройки кнопкой в правом углу вверху и перейдите в раздел «Безопасность». Разблокируйте параметры безопасности.
2. Откроется новое окно. Если появится запрос со стороны UAC – «Контроля учётных записей» – нажмите «Да». Короткий путь – кликните «Изменить пароль доступа…» в основном окне.
3. Активируйте опцию «Разрешить неконтролируемый доступ». Введите надёжный пароль и подтвердите его. После станет активной «Применить», необходимо нажать по ней.
4. Сообщите пароль и идентификатор оператору. При очередном подключении к текущему компьютеру необходимо ввести пароль. Для пропуска окна с запросом в следующий раз активируйте опцию «Входить автоматически».

Настройка неконтролируемого доступа на android

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

1. Тапните «Изменить пароль…».
2. Разрешите подключение без запроса – нужна будет галочка возле соответствующего пункта. Далее нужно ввести пароль.
3. В расположенном ниже подразделе «Другим пользователям AnyDesk…» можете ограничить права оператора.

Настройки безопасности

Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера – Конфигурация Windows – Политики безопасности – Локальные политики – Параметры безопасности, в этом разделе найдем политикуСетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр DWORDс именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя.

Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Я надеюсь, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

Материал сайта vhod-v-lichnyj-kabinet.ru

Ограничения для неконтролируемого входа

Возможности оператора для интерактивного доступа по управлению удалённой машиной изменяются при подключении без запроса:

1. Кликните «Изменить пароль…».
2. Опуститесь к подразделу «Другим пользователям ЭниДеска разрешено…» и снимите флажки возле опций, которые стоит запретить.
3. Закройте окно, изменения сохранятся автоматически.

Сброс входа без подтверждения в anydesk

Для закрытия неконтролируемого доступа выполните инструкцию.

1. Тапните по иконке слева вверху.
2. Войдите в раздел «Настройки» для сброса доступа.
3. Нажмите «Удалить токены авторизации» и снимайте указанные флажки.
4. Окно можно закрывать, изменения подтверждать не нужно.

Среда исполнения

В рассматриваемом примере будет создан Windows NLB кластер из двух виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2022 R2 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2022 R2 Standard EN.

Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.

Серверам присвоены имена – KOM-AD01-VPN01 и KOM-AD01-VPN02.

Создаваемый в процессе описания NLB-кластербудет использовать имя KOM-AD01-VPNCL.

В качестве поставщика аутентификации будут использоваться два отдельных сервера внутри локальной сети с заранее установленной и настроенной ролью Network Policy and Access Services (RADIUS) с именами KOM-AD01-NPS01 и KOM-AD01-NPS02.

Аутентификация для протокола L2TP/IPsec с использованием сертификатов потребует наличия Доменного или Автономного Центра сертификации (ЦС) для создания цифровых сертификатов для VPN-клиентов. В рассматриваемой конфигурации а качестве Автономного ЦС будет использоваться отдельный сервер внутри локальной сети с именем KOM-AD01-CA01  

Упрощённая схема взаимодействия компонент конфигурации будет выглядеть следующим образом:

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

Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал PPTP VPN и протестируем его. Если на этом этапе проблем выявлено не будет, следующим этапом приступим к связке сервера VPN c RADIUS, и снова проверим результат.

В случае успешной проверки авторизации через RADIUS перейдём к настройке VPN-сервера и VPN-клиентов для поддержки протокола L2TP/IPsec. Снова проверим результат, и в случае успеха перейдём к окончательному этапу – созданию второго VPN-сервера аналогичной конфигурации и построению NLB-кластера из двух VPN-серверов. Таким образом, план развёртывания конфигурации будет следующим:

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)1.1. Настройка виртуальной машины1.2. Установка роли Remote Access1.3. Настройка службы Routing and Remote Access1.

4. Настройка правил Windows Firewall2. Проверка подключения по протоколу PPTP3. Создание доменных групп доступа4. Работа с серверами NPS/RADIUS4.1. Создание основной сетевой политики на сервере NPS4.

2. Создание дополнительной сетевой политики NPS для PPTP-подключений4.3. Добавление информации о VPN-сервере на сервер RADIUS5. Привязка VPN-сервера к серверам RADIUS6. Проверка подключения по протоколу PPTP с использованием RADIUS 7.

Работа с сертификатами7.1. Установка корневого сертификата ЦС на VPN-сервере и клиенте.7.2. Создание сертификата VPN-сервера7.3. Создание сертификата VPN-клиента8.

Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec9. Настройка второго VPN-сервера (KOM-AD01-VPN02)10. Создание NLB-кластера из двух VPN-серверов11. Проверка работы NLB-кластера12. Разработка инструкций для пользователей.

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Удаленный доступ в windows 8

Данный обзор был бы не полным, если бы мы не рассмотрели возможности самой ОС. На «сервере» (то есть на компе, к которому планируется удаленный доступ) нужно выполнить следующие действия:

• Запустить SystemPropertiesRemote.exe.
• Включить флажок «Разрешить подключения удаленного помощника к этому компьютеру».
• Включить переключатель «Разрешить удаленные подключения к этому компьютеру» и нажать кнопку «Применить».
• Если используется энергосберегающий режим, нужно настроить комп так, чтобы он никогда не переводился в спящий режим.

На своем компе используй приложение «Подключение к удаленному рабочему столу» для подключения к удаленному компу.

Шаг 1: установка спец. приложения

Для решения выше-оговоренной задачи – нам понадобиться спец. программа – AnyDesk (ссылка на офиц. сайт). Кстати, у нее есть 👉 десятки программ-аналогов (правда, не у всех есть нужные нам опции…).

Почему именно она?

Всё просто: она бесплатная для личного использования, и к тому же обеспечивает большее количество FPS при подключении.

Т.е. изображение с другого ПК у вас на мониторе будет более качественным и плавным. Например, тот же TeamViewer дает около 25-30 FPS, AnyDesk — 50-60 FPS (при одинаковых исходных данных). Делайте выводы 👌

Что касается установки: то она крайне простая…

Сначала загружаете AnyDesk с офиц. сайта и запускаете программу на том компьютере, к которому вы хотите в последствии подключаться.

Далее:

1. записываете (или запоминаете) ID этого компьютера (эти цифры будут нужны в последствии для подключения к нему);
2. в меню, слева, кликните по ссылке “Установить AnyDesk на этот компьютер”.

Проверяете, чтобы стояли все галочки (как в примере ниже) и нажимаете “Принять”.

Всё! Теперь программа AnyDesk будет автоматически стартовать вместе с Windows при каждом включении ПК (а значит к этому ПК можно будет подключаться, не прося пользователя что-то там запустить…).

Шаг 2: открываем удаленный доступ и ставим пароль

Теперь на этом же ПК (к которому мы хотим подключаться) в программе AnyDesk открываем раздел настроек. См. скрин ниже.

Во вкладке “Безопасность” кликаем по кнопке “Разблокировать настройки безопасности”. (могут понадобиться администраторские права)

После, ставим галочку напротив пункта “разрешить неконтролируемый доступ” и задаем пароль.

Примечание: эта опция позволяет нам подключаться к этому ПК без разрешения пользователя!

То есть, если вам звонит ваша бабушка и просит посмотреть, что творится с ее ПК — вам не придется ей объяснять, чтобы она запустила AnyDesk и дала разрешение на подключение к ее устройству. Просто скажите ей: “Включи ПК, и дальше я сделаю всё сам!..”.

Важно!

Этот пароль нужно также запомнить/записать (вместе с ID, который был в 1-ом ШАГЕ) — он будет нужен для удаленного подключения к этому ПК.

Всё, собственно, на этом вся настройка на этом компьютере завершена…

Шаг 3: подключение и управление 👌

Теперь устанавливаем AnyDesk на том компьютере, с которого вы будите подключаться к другим ПК, наблюдать за их рабочим столом, управлять файлами и т.д.

Далее в строку “Удаленное рабочее место” вводим ID того ПК/ноутбука, к которому нужно подключиться (ID мы знаем из ШАГА 1). После, AnyDesk попросит указать пароль от него (мы его тоже знаем из ШАГА 2) — если данные верны, вы получите доступ к удаленному компьютеру!

Для “непосвященных”: вы можете управлять чужим компьютером по Интернет и работать с его рабочим столом как со своим собственным (см. скриншот ниже 👇).

Это очень удобно, когда вам кто-то звонит из знакомых и слезно просит помочь исправить какую-нибудь мелочь (ошибку, например). А учитывая, что мы можем подключаться без его “телодвижений” — это экономит уйму времени!

Примечание: рядом с кнопкой чата есть и другие опции. Например, вы можете перезагрузить или выключить удаленную машину, что-то нажать на клавиатуре и т.д.

Шаг 4: передача и загрузка файлов с удаленного пк

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

Во-первых, можно просто что-нибудь скопировать и вставить как при обычной работе с проводником (это при использовании последней версии ПО и Windows 10).

Во-вторых, обратите внимание на главное окно AnyDesk – для того ПК/ноутбука, к которому вы ранее подключались, будет создан профайл (иконка рабочего стола с его ID). 👇

Если нажать по “трем точкам” — появится заветная ссылка “начать передачу файлов”. Откройте ее!

Собственно, далее появится окно: слева — ваш диск, справа — диск удаленного ПК. Вам осталось только выбрать файлы и нажать на кнопку “Загрузки” или “Скачивания”. В общем-то, работа крайне простая… 👌