Вход по RDP¶
Та же карта открывает удалённый рабочий стол: сотрудник подключается к доменной машине, вводит PIN и не вводит пароль нигде. Цель получает доказательство того, что ключ у него, а сам ключ машину не покидает.
Настройка входа и выдача сертификата — в «Настройке»; здесь только то, что относится к подключению.
Клиент RDP запускает человек, а не Alatyr
Alatyr не подменяет собой клиент: карта обязана подхватываться в обычном
mstsc или другом клиенте сама. Команда alatyr-agent rdp и раздел в окне
агента объясняют, почему карта не появилась, и проверяют готовность.
Шаг 1. Подготовьте машину-цель¶
Это делает администратор той машины, куда будут входить.
- Зарегистрируйте минидрайвер. Карта приезжает к цели пробросом, но читать её нечем, пока там не зарегистрирован минидрайвер Alatyr: Windows не знает её и показывает на экране входа «Connect a smart card» при полностью исправной остальной цепочке. Считыватель цели не нужен, только регистрация:
alatyr-agent install-reader --minidriver-only
- Включите NLA. С включённой проверкой подлинности на уровне сети переподключение к отключённому сеансу по карте проходит; с выключенной — Windows переаутентифицирует человека без возможности показать диалог, и карте негде спросить PIN.
- Разрешите Remote Credential Guard, если вход идёт этим путём:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa→DisableRestrictedAdmin = 0. - Не оставляйте отключённые сеансы жить — полезная гигиена, брошенные сеансы копятся и занимают ресурсы:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
MaxDisconnectionTime = 60000 (мс; здесь — минута)
fResetBroken = 1 завершать сеанс по истечении срока
Через групповые политики: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Session Time Limits.
Результат. На цели зарегистрирован минидрайвер, NLA включён.
Шаг 2. Включите проброс карты в сеанс¶
Цель просит карту у себя: без проброса сеанс не создаётся, и человек видит экран входа с надписью «Connect a smart card». Выглядит это как отказ, хотя PIN принят и канал построен.
Галочку не нужно ставить в каждом подключении — достаточно включить проброс в умолчаниях клиента:
alatyr-agent rdp --enable-redirect
Команда правит %USERPROFILE%\Documents\Default.rdp, сохраняя остальные
строки, и говорит, что именно изменила. Повторный вызов файл не трогает.
Отменить — строкой redirectsmartcards:i:0 в том же файле.
Правка делается только по явной просьбе: Default.rdp принадлежит человеку
и влияет на все его подключения, а не только на карточные.
Руками этот файл лучше не править
Он записан в UTF-16LE с меткой порядка байт, а клиент RDP создаёт его скрытым — запись поверх скрытого файла Windows отклоняет с «Access is denied», хотя файл читается и права на него есть.
Запускать подключение из .rdp-файла — не надо
Запуск из файла тянет два диалога, и второй сбрасывает галочку
проброса, игнорируя redirectsmartcards:i:1, записанный в самом файле.
Результат. mstsc /v:<полное-доменное-имя> не показывает ни одного диалога
согласия, а окно учётных данных сразу открывается карточной плиткой.
Шаг 3. Подключитесь¶
Сначала проверьте готовность — это делает окно агента:
- Откройте окно Alatyr.
- В разделе «Подключение по RDP» впишите адрес машины — полное доменное
имя, например
pc-203.example.local. - Окно покажет, что готово, а что нет. PIN на этом шаге не нужен.
То же из командной строки:
alatyr-agent rdp --target pc-203.example.local
Когда отчёт зелёный — открывайте свой клиент RDP обычным способом
(mstsc /v:pc-203.example.local) и вводите PIN карты в диалоге Windows.
Отчёт печатает по строке на каждое условие и заканчивается либо готово: можно
подключаться, либо подключение не готово. Подключаться до зелёного отчёта
бессмысленно: неготовность выглядит как отказ входа.
| строка | что проверяется |
|---|---|
target |
адрес — полное доменное имя. У IP-адреса входа по карте не бывает: у него нет имени службы, Kerberos невозможен, и подключение молча спросит пароль |
policy |
политика Remote Credential Guard на этой машине; ставится командой alatyr-agent rdp --setup-policy от администратора |
card |
карта поднята и её сертификат на месте |
client |
клиент RDP (mstsc.exe) найден |
lsa |
защита LSA — пускает ли она минидрайвер; см. ниже |
Запускайте команду от имени владельца карты. Карта живёт в профиле своего владельца, и от другой учётной записи её попросту нет — включая запуск «от администратора», если это другая учётная запись.
Результат. Открылось обычное окно удалённого рабочего стола. Пароль вы нигде не вводили.
Галочку «Смарт-карты» Windows спрашивает каждый раз
После запуска клиент показывает согласие «Unknown remote connection» со снятой галочкой «Smart cards or Windows Hello for Business». Без неё карта в сеанс не уезжает, а удалённый экран говорит лишь «Connect a smart card». Windows сбрасывает её на каждый запуск — так написано в самом диалоге, и обойти это настройкой реестра нельзя.
Плитка карты — не первая на экране входа, и это нормально
На пути без NLA удалённый экран показывает не карточную плитку, а Other
user с длинным именем вида @@B… и поле Password. Выглядит как отказ, но
карта проброшена, и до неё два клика: «Sign-in options» → значок
смарт-карты. Дальше появится плитка с ФИО из сертификата, UPN и полем
PIN. Настраивать тут нечего — так ведёт себя экран входа Windows, когда
клиент передаёт карточные учётные данные без NLA.
Если карта не доходит до NLA: защита LSA на клиенте Windows¶
CredSSP (то, что делает NLA) работает внутри lsass.exe, а тот запущен
защищённым процессом и пускает только модули с подписью Microsoft. Минидрайвер
Alatyr там блокируется, и Windows говорит об этом прямо:
This module is blocked from loading into the Local Security Authority.
Защита LSA — умолчание Windows 11, а не особенность конкретной машины. Remote
Credential Guard этого требования не обходит: билет по PKINIT добывает
Kerberos внутри того же lsass.exe.
Сообщение Windows при этом уводит в сторону — на экране клиента видно «An
authentication error has occurred. The function requested is not supported» и
подсказку про NTLM и CredSSP, к делу не относящуюся. Поэтому агент проверяет
это сам строкой lsa в отчёте готовности.
Обходной путь — проброс карты с выключенным на цели NLA: снимите в окне
галочку «Без Remote Credential Guard» (или --no-remote-guard) и войдите
на удалённом экране. Карту там пробрасывает клиент RDP из пользовательского
сеанса, lsass.exe клиента в этом не участвует, и защита LSA пути не мешает.
Требование подписи снимается не настройкой на вашей стороне: пока минидрайвер не подписан Microsoft, этот путь закрыт устройством Windows, а не Alatyr.
Клиентскую политику Remote Credential Guard включать не надо
RestrictedRemoteAdministration=1 + Type=2 принуждают к Remote
Credential Guard каждое подключение. Выглядит это как «подключилось само,
ничего не спросив»: делегируется уже имеющийся билет, вход идёт по паролю,
экран входа не появляется вовсе — и карточную плитку на нём увидеть нельзя.
Заодно ломаются подключения к недоменным целям. mstsc /remoteGuard
работает и без политики.
С Linux¶
Карта здесь клиентская: Linux открывает удалённый рабочий стол Windows. Локального входа в Linux по карте нет.
xfreerdp3 /v:pc-203.example.local /u:ivanov /d:example.local \
/smartcard-logon /sec:nla
Клиент спросит PIN карты. Цель называйте именем, а не адресом: по адресу Kerberos не находит имени службы, вход молча уходит в NTLM, и на контроллере домена не появляется ни одного события 4768 — при внешне успешном подключении.
Три вещи ставятся на машину один раз и не входят в поставку агента. Без любой из них вход не идёт, а клиент сообщает об этом так, что причина не угадывается.
- Клиент с поддержкой Kerberos:
apt-get install freerdp3-x11 # bookworm-backports
freerdp2 из Debian не годится: он собран без Kerberos, и карточный
CredSSP в нём невозможен. Проверить свою сборку:
xfreerdp3 /buildconfig | tr ' ' '\n' | grep -E 'WITH_KRB5|WITH_SMARTCARD_PCSC'
# ожидание: WITH_KRB5=ON WITH_SMARTCARD_PCSC=ON
- Модуль PKINIT для Kerberos:
apt-get install krb5-pkinit
Без него клиент молча откатывается на пароль, которого у карты нет, и
отвечает Preauthentication failed.
- Две строки в
/etc/krb5.conf:
[libdefaults]
pkinit_anchors = FILE:/путь/к/цепочке-доменного-УЦ.pem
[realms]
EXAMPLE.LOCAL = {
kdc = dc.example.local
pkinit_kdc_hostname = dc.example.local
}
pkinit_anchors — чем проверять сертификат контроллера домена. Без
pkinit_kdc_hostname MIT krb5 отвергает его с KDC name mismatch: Active
Directory кладёт имя в сертификат иначе, чем ждёт MIT.
Считыватель ставится один раз:
sudo alatyr-agent install-reader --purpose ad_logon
Саму карту поднимает агент — вручную ничего запускать не нужно. Проверить:
opensc-tool -l # ожидание: Alatyr Smart Card Reader … Yes
Yes в колонке Card означает, что карта в считывателе.
Порядок установки считывателя важен
pcscd проверяет путь сокета при разборе конфигурации и, не найдя файла,
завершается с ошибкой вместе со всеми остальными считывателями машины.
Поэтому install-reader перезапускает демон только тогда, когда карта уже
слушает. Если ставите строку руками — сначала карта, потом systemctl
restart pcscd.
Клиент запускает владелец сертификата
Ключ и якоря PKINIT живут в домашнем каталоге владельца, а узел TPM
принадлежит отдельной группе. У постороннего пользователя нет ни того ни
другого, и клиент отвечает Preauthentication failed /
ERRCONNECT_LOGON_FAILURE. Отличается от настоящего отказа одним
признаком: на контроллере домена события 4768 нет вовсе — до него дело не
дошло.
С macOS¶
Вход в RDP по карте с Mac работает, но ни один готовый клиент этого не даёт: в FreeRDP поддержка Kerberos на macOS выключена по умолчанию в самом проекте, наравне с iOS и Android. Штатный Windows App, Thincast и сборка из Homebrew видят считыватель и пробрасывают карту в сеанс, но войти по ней не могут.
Отказ при этом выглядит как «карта не подошла»: подключение доходит до NLA и
падает ERRCONNECT_LOGON_FAILURE, а клиент откатывается на NTLM, по которому
карточный вход невозможен по построению. Проверить свой клиент одной командой:
otool -L /path/to/libwinpr3.*.dylib | grep krb5 # пусто = карточного входа не будет
Нужна сборка FreeRDP с Kerberos. Подключение затем выглядит так:
KRB5_CONFIG=<ваш krb5.conf> <ваш собранный клиент> \
/v:<машина>.<домен> /d:<домен> /u:<логин> /sec:nla \
"/smartcard-logon:reader:Alatyr Smart Card Reader" \
"/kerberos:pkinit-anchors:FILE:<цепочка-УЦ>.pem,pkcs11-module:/opt/homebrew/lib/opensc-pkcs11.so"
Чем доставлять такой клиент сотрудникам — открытый вопрос, готового ответа у продукта нет. Подробнее об ограничениях macOS — в пределах.
Клиент вне домена: списки отзыва контроллера¶
Машина, не присоединённая к домену, не может проверить, не отозван ли сертификат контроллера домена, и вход по карте падает до сеанса:
An authentication error has occurred.
The revocation status of the domain controller certificate used for
smartcard authentication could not be determined.
Причина не в карте. УЦ Windows по умолчанию публикует точки распространения списков отзыва (CDP) и адреса издателя (AIA) только по LDAP, а неприсоединённая машина в LDAP домена не ходит.
Что делает Alatyr. Агент забирает списки отзыва у сервера (тот в домен
ходит) и ставит их в LocalMachine\CA на каждом машинном цикле — обе:
базовую и delta. С одной базовой статус остаётся неизвестным, потому что
сертификат ссылается на delta. Свежесть тоже обязательна: просроченный список
даёт ровно тот же отказ, что и его отсутствие, — поэтому обновление идёт
постоянно, а каждый его исход попадает в журнал агента.
Проверить на машине:
certutil -verify -urlfetch dc.cer
dwErrorStatus=0 на обоих уровнях цепочки — списки на месте и свежие.
Требование к вашему УЦ: HTTP-точка CDP и AIA
Локальная доставка списков — компенсация, а не замена правильной настройке. Если у организации есть клиенты вне домена, у выпускающего УЦ должна быть HTTP-точка распространения: до неё такая машина дотягивается сама, без участия Alatyr и без задержки на его цикл. При наличии HTTP-точки продукт её не дублирует — доставляются только LDAP-точки, потому что только они клиенту недоступны.
Если сервер списки не отдаёт, в журнале агента будет строка с причиной:
| причина в журнале | что чинить |
|---|---|
| каталог не настроен | ALATYR_DIRECTORY_URL пуст — шаг 5 настройки |
| «в каталоге нет точки распространения для …» | учётной записи привязки не хватает прав на раздел конфигурации леса, либо УЦ вообще не публикует список в каталог |
| «в BaseDN … нет ни одного компонента DC=» | ALATYR_DIRECTORY_BASE_DN задан без доменных компонентов |
Если не получилось¶
| Что видно | Причина и что делать |
|---|---|
card нет, путь ведёт в чужой профиль |
команда запущена не от владельца карты |
policy нет |
alatyr-agent rdp --setup-policy от администратора |
lsa нет, «The function requested is not supported» с упоминанием NTLM/CredSSP |
защита LSA не пускает минидрайвер; снимите галочку «Без Remote Credential Guard» и входите пробросом карты |
| «No credentials are available in the security package» | политика Remote Credential Guard не настроена на этой машине или на цели |
| «The selected user credential requires that local smart card … be made available to the remote session» | в подключении выключен проброс смарт-карт — шаг 2 |
| «Connect a smart card» на удалённом экране | на цели не зарегистрирован минидрайвер (шаг 1), либо проброс не включён |
| «The revocation status of the domain controller certificate … could not be determined» | машина вне домена без локальных списков отзыва — см. раздел выше |
| «Provider could not perform the action since the context was acquired as silent» | переподключение к отключённому сеансу при выключенном на цели NLA — включите NLA (шаг 1) |
| подключение прошло, но пароль всё-таки спросили | цель задана IP-адресом, а не полным доменным именем |
Успех на стороне домена виден так: на контроллере домена 4768 с вашим УЦ в
издателях и Result Code 0x0, следом 4769; на цели — 4624 с типом
входа 10. Отсутствие ошибок у клиента успехом не является: соединение может
упасть раньше, например на разрешении имени.
Что дальше¶
- Пределы и нюансы — почему нет локального входа по карте, почему ключ RSA и что произойдёт в день истечения сертификата.
- Настройка — вернуться к порядку: домен, админка, устройство.