Исправить ошибку 0x80090010 в доступе создания подписи ключа |

Двухуровневый tls

В случае аутентификации пользователей об Active Directory по сертификатам RSA я предлагаю использовать обычный TLS c хранением клиентского ключа аутентификации RSA на Рутокен ЭЦП, но ходить через sTunnel. В этом случае TLS по RSA будет передаваться внутри канала TLS c ГОСТ.

Возможны две схемы. В первой TLS с RSA организует непосредственно клиент RDP. При этом на токене хранятся два ключа — ГОСТовый (аутентификация «свой-чужой», чтобы авторизоваться на сервере sTunnel)и RSA (если пользователь смог пройти первый барьер, то этот ключ используется для аутентификации об AD, пользователь сразу попадает в свою учетную запись на RDP-сервере).

Для доступа к ключу/сертификату RSA, хранящимся на Рутокен ЭЦП, и аппаратной реализации RSA на «борту» Рутокен ЭЦП используется на Windows Рутокен CSP (входит в дистрибутив драйверов Рутокен), на Linux приложение rdesktop работает через PC/SC.

Во второй схеме TLS по RSA и по ГОСТ обеспечивается самим sTunnel. Сразу предупреждаю, что эту вторую схему я не пробовал.

Для доступа к ключу RSA и аппаратной реализации RSA «на борту» Рутокен ЭЦП используется engine pkcs11 из проекта OpenSC www.opensc-project.org/engine_pkcs11.

Соответственно, в конфиге клиента sTunnel будут две секции:

[RDP-TLS-GOST]
engineNum=1
key=100
cert=client_gost.crt
accept = 127.0.0.1:8088
connect = x.x.x.x:1494
ciphers = GOST2001-GOST89-GOST89
TIMEOUTclose = 1


[RDP-TLS-RSA]
engineNum=2
key=101
cert=client_rsa.crt
accept = 127.0.0.1:8087
connect = 127.0.0.1:8088
TIMEOUTclose = 1

А ходить клиентом RDP надо на 127.0.0.1:8087.

Демонстрация работы azure mfa для аутентификации rdg подключений

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

Первым делом, пользователю понадобиться зайти на пользовательский портал и указать свой номер телефона (если не указан в AD) и привязать к аккаунту мобильное приложение. Заходим на портал под своей учетной записью и вводим ответы на секретные вопросы (они нам понадобятся в случае восстановления доступа к аккаунту).

Далее выбираем метод аутентификации, в нашем случае мобильное приложение и нажимаем кнопку «Создать код активации». Будет сгенерирован QR код, который надо отсканировать в мобильном приложении.

Так как при импортировании пользователей на MFA сервер была выставлена аутентификация с помощью PIN кода, нам будет предложено создать его. Вводим желаемый PIN код и нажимаем «Проверить мою подлинность». В мобильном приложении необходимо подтвердить появившийся запрос.

Примечание: Список настроек, которые может менять пользователь через портал, задаётся администратором в приложении Multi-Factor Authentication Server.

Далее рассмотрим подключение через RDG.

Создаем RDP подключение, указываем наш шлюз и подключаемся.

Вводим данные учетной записи для авторизации на RDG сервере.

Подтверждаем запрос в мобильном приложении

Вводим данные учетной записи для авторизации на подключаемой машине и ожидаем подключения.

Примечание: Если телефон оснащен датчиком отпечатка пальца, приложение Authenticator предложит связать PIN код с отпечатком пальца, чтобы в последующем подтверждать аутентификацию простым прикосновением к телефону.

Способы аутентификации, которые предлагает Azure MFA:

Звонок телефона:

SMS – можно использовать OTP или OTP PIN:

Мобильное приложение:

OATH token – при авторизации необходимо будет ввести в дополнительное поле код с экрана токена. В качестве токена можно использовать мобильное приложение.

Способы SMS One-Way и OATH token не являются универсальными, так как требуют дополнительного поля для ввода кода при авторизации.

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

На портале Azure в панели управления MFA можно включить возможность, позволяющую пользователям отмечать пришедший запрос на аутентификацию как мошеннический. Также возможна автоматическая блокировка пользователя при получении данного сообщения и отправка email уведомления службе поддержки.

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

В панели управления Azure MFA есть отчет отображающий уведомления о мошенничестве:

Если необходимо узнать IP адрес, с которого была инициализирована RDP сессия, можно посмотреть логи RDG сервера в Event Viewer. Если второй фактор аутентификации не был пройден, событие будет иметь статус Error, а в описании будет указан IP адрес, с которого устанавливалось RDP соединение.

Ссылки по статье:

Конфигурирование автоматического выпуска сертификатов

Переходим в Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies и выбираем Certificate Services Client — Auto-Enrollment Включаем автоматический выпуск сертификатов а так же настройки по их автоматическому обновлению:

Настройка rdg и nps сервера на работу совместно с mfa

Шлюз удаленных рабочих столов необходимо настроить на отправку Radius запросов на сервер MFA. Для этого открываем свойства шлюза и переходим на вкладку «RDG CAP Store», выбираем «NPS работает на центральном сервере» и указываем адрес MFA сервера и общий секретный ключ.

Далее производим настройку NPS сервера. Разворачиваем раздел «Клиенты и серверы Radius → Удаленные группы серверов Radius». Открываем свойства группы «TS gateway server group» (группа создаётся при настройке RDG) и добавляем наш MFA сервер.

При добавлении, на вкладке «Load Balancing» увеличиваем лимиты времени ожидания сервера. Выставляем «Число секунд без ответа, после которого запрос считается отброшенным» и «Число секунд между запросами, после которого сервер считается недоступным» в диапазоне 30—60 секунд.

На вкладке «Authentication/Accounting» проверяем правильность указанных портов и задаем общий секретный ключ.

Теперь перейдем в раздел «Клиенты и серверы Radius → Клиенты Radius» и добавим MFA сервер, указав «Friendly name», адрес и общий секрет.

Переходим в раздел «Политики → Политики запросов на подключение». В данном разделе должна быть политика, созданная при настройке RDG. Эта политика направляет запросы Radius на MFA сервер.

Дублируем политику и заходим в ее свойства. Добавляем условие сопоставляющее «Client Friendly Name» c «Friendly name», заданным в предыдущем шаге.

На вкладке «Settings» меняем поставщика услуг аутентификации на локальный сервер.

Данная политика будет гарантировать то, что при получении Radius запроса от MFA сервера, запрос будет обработан локально, что избавит от зацикливания запросов.

Проверяем что данная политика размещена над исходной.

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

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

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

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

Это позволит избавиться от ошибки с кодом 0x80090010, когда отказано в доступе в программе «Континент» АП.

Также может помочь следующая процедура, особенно актуальная в случае Крипто-Про 4.0:

1. Запустите ваш «Крипто-Про», и выберите там вкладку «Сервис»;
2. Далее нажмите на «Просмотреть сертификаты в контейнере»;
3. Затем нажмите на вкладку «Обзор», и выберите нужный сертификат;
4. Далее кликните на «Свойства», затем «Состав»;
5. Затем выберете «Копировать в файл», не забыв поставить галочки на опциях «Да, экспортировать закрытый ключ» и «Экспорт расширенных свойств»;
6. Задайте имя и пароль для сертификата;
7. Экспортируйте файл с расширением .pfx;
8. Установите снова этот файл, и присвойте ему контейнер с новым именем;

Сертификат Континент АП будет необходимо установить с привязкой к данному контейнеру с новым именем, и дисфункция 0x80090010 (отказано в доступе) исчезнет.

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

Подключение к серверу по rdp из ubuntu

RDP – это закрытый протокол компании Microsoft, она же в свою очередь не выпускает RDP-клиентов для операционных систем семейства Linux.

Однако всё же есть различные рабочие версии от тех или иных производителей.

Мы рекомендуем использовать клиент

Remmina

Для пользователей Ubuntu есть специальный репозиторий с различными пакетами приложение, в числе которых есть Remmina и RDP.Установка производится в 3 простые команды, которые вводятся по очереди в Терминале:

Для установки пакета Remmina

sudo apt-add-repository ppa:remmina-ppa-team/remmina-next

Устанавливаем обновления

sudo apt-get update

Устанавливаем плагин протокола RDP

sudo apt-get install remmina remmina-plugin-rdp libfreerdp-plugins-standard

Если вы до этого уже устанавливали или запускали существующую версию Remmina, то её необходимо перезапустить. Сделать это можно перехагружкой компьютера, либо выполнением следующей команды в том же терминале:

sudo killall remmina

Если процесс запущен не был, то появится сообщение об ошибке: процесс не найден, что тоже нас устраивает.

Открываем меню поиска и находим там свежеустановленный пакет Remmina

Нажимаем на добавление нового подключения и заполняем поля данными для подключения и авторизации к вашему серверу (где находятся данные для подключения к именно вашему серверу описано выше):

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

При первом подключении к серверу вы можете увидеть информацию о недоверенном сертификате безопасности. Причина этого описана выше. Просто нажмите «ОК» и вы увидите рабочий стол вашего сервера.

Порядок получения сертификата континент-ап

Причины ошибки с кодом 0x80090010: отказано в доступе в континент ап

Как известно, АП «Континент» — это аппаратно-программный комплекс, обеспечивающий защиту информационных сетей от вторжений со стороны Интернета. Комплекс гарантирует конфиденциальность передачи данных по открытым каналам связи с помощью VPN, и имеет высокую степень доверия со стороны государственных структур Российской Федерации, а также различных бизнес-структур.

Одной из популярных проблем при работе АП «Континент» является подпись с ошибкой № 0x80090010 (отказано в доступе). Она появляется при попытке подписания документов, выполнения сеанса сетевой связи с другими системными фискальными элементами и другими смежными операциями.

Причины для этого могут быть следующие:

Также причиной может быть использование устаревшей версии системы Крипто-Про. Давайте разберём способы, позволяющие исправить подпись с кодом 0x80090010, когда может быть отказано в доступе в программе Континент АП.

Вас также заинтересует: «Этот сертификат содержит недействительную цифровую подпись» в КриптоПро.

Проверка работоспособности

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

1. Отсутствие в правильной группе безопасности, которая указана в шаблоне;
2. Отсутствие к ЦС необходимых сетевых портов от клиента. Напомню, это tcp/135 (RPC) и динамические порты tcp/49152—65535.

Проверить что сертификат был успешно выпущен можно в консоли ADCS:

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

Решение №2. подбор пин-кода и права администратора

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

Иногда количество попыток ввода можно увеличить. Для этого нужно зайти на токен в качестве администратора и разблокировать пин-код:

1. Перейти в панель управления токеном. Например, если используется носитель «Рутокен», то нужно перейти в Пуск — Панель управления — Панель управления «Рутокен» — вкладка «Администрирование».
2. Ввести пин-код администратора. Стандартное значение устанавливает производитель: для «Рутокена» — 87654321, для Jacarta SE — 00000000 для PKI-части и 1234567890 для ГОСТ части. Если стандартное значение администратора не подошло, значит его сменили, и нужно вспоминать установленную комбинацию. На это есть десять попыток, потом токен окончательно заблокируется.
3. Разблокировать пин-код токена. Для этого на вкладке «Администрирование» нажать «Разблокировать».

Также, если пин-код администратора известен, то можно сбросить попытки ввода другим способом — через КриптоПро CSP:

1. Открыть КриптоПро CSP, перейти на вкладку «Оборудование» и нажать кнопку «Настроить типы носителей».
2. Выбрать свой токен. Открыть его свойства и перейти в раздел «Информация».
3. Разблокировать пин-код.

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

Если вспомнить или изменить нужную комбинацию не удалось, придется получать новый сертификат подписи в УЦ: отозвать старый сертификат и получить новый. Токен можно использовать старый — можете отформатировать носитель, тогда старый пин-код и сертификат удалятся.

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

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

Перед реализацией дальнейших решений, проделайте предыдущие действия указанные в начале статьи. В случае безрезультатности последних —  вывод только один — вы используете версию Crypto-Pro 4.0. Недостаток последней заключается в том. что Крипто-Про 4.0 воспринимает ключи, созданные 15 месяцев назад как просроченные (хотя срок «годности» 2 года).

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

1. Воспользуйте элетронной печатью на другом компьютере. Зачастую возникшая проблема состоит именно в программном обеспечении или «железе» ПК. В случае успеха — переустановите систему первому компьютеру.
2. Обратитесь в техническую помощь, возможно ключ сделан с ошибкой. Попробуйте воспользоваться электронной подписью коллеги (если таковой имеется). Таким образом узнаем работоспособность программного обеспечения и железа, к которому подключен ключ
3. Ошибки могут возникать в случае, когда ключ создан был только недавно, активация еще не прошла. В таком случае — необходимо немного подождать и проверить снова. Зачастую такая проблема возникает в государственных органах с новыми сотрудниками. Подпись выдается сразу, работать начинает на следующий день.
4. В случае отсутствия антивируса на компьютере — установите и проверьте последний путем углубленной проверки. Очистите компьютер от вредоносных программ, которые приводят к поломке как установленные программы, так и систему вцелом.
5. При безрезультатности всех вышеперечисленных методов решения проблемы 0x80090010, рекомендуем обратиться непосредственно в техническую поддержку за заменой действующего ключа.

Сертификат континента ап

Создание шаблона сертификата rdp в adcs

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

Дублируем сертификат Computer

Задаем имя будущего шаблона:

Указываем настройки совместимости:

В Extensions, необходимо задать правильные Application Policies для  поддержки TLS в RDP протоколе

Для этого удаляем Client Authentication и Server Authentication и добавляем Remote Desktop Authentication с OID 1.3.6.1.4.1.311.54.1.2, как показано на скриншоте:

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

Завершающим шагом будет его выпуск на выдающем корпоративном ЦС:

Установка своего сертификата для rdp

Устранение ошибки err cert date invalid неверный сертификат