Перейти к содержанию

Пределы и нюансы

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

Только SCEP/ADCS: Vault для этой цели не подходит

Windows пускает по карте, только если сходятся шесть условий сразу:

  1. в сертификате EKU smartCardLogon и clientAuth;
  2. в сертификате SAN с UPN сотрудника;
  3. в сертификате SID сотрудника — обязателен при строгом сопоставлении сертификата с учётной записью (KB5014754, действует в домене по умолчанию);
  4. выпускающий УЦ опубликован в хранилище NTAuth;
  5. корню этого УЦ доверяют для входа по карте все контроллеры домена и клиенты;
  6. закрытый ключ предъявляется Windows как ключ смарт-карты.

Пункты 1–3 и 6 — работа Alatyr. Пункты 4 и 5 — конфигурация вашего леса, и Alatyr их не делает: смена состава NTAuth или политики доверия корню действует на каждый вход по карте в домене. Это разовая операция на срок жизни УЦ, а не действие на каждое устройство.

Из третьего пункта следует единственный возможный источник выпуска: Vault PKI не умеет выпускать SID вовсе, поэтому «Вход в AD» — единственная цель с жёстко зафиксированным бэкендом. Сервер требует SCEP и отклоняет любую другую настройку независимо от того, что выбрано в интерфейсе.

Отозвать такой сертификат через Alatyr нельзя

В протоколе SCEP нет операции отзыва. Кнопка отзыва в интерфейсе для SCEP-выпущенных сертификатов отключена, а обращение к API вернёт ошибку. Отзывать сертификаты «Входа в AD» нужно на стороне вашего ADCS, и там же следить за публикацией списков отзыва.

Подробнее — Известные ограничения.

Ключ обязан быть RSA

Причин две, и обе не про Alatyr:

  • Минидрайвер PIV Windows заводит контейнер только для сертификата на ключе RSA. На ключе ECDSA он отказывает сам, не задав карте ни одного вопроса.
  • Шаблон ADCS задаёт минимальную длину ключа, и ECDSA P-256 он считает 256-битным: выдача падает с CERTSRV_E_KEY_LENGTH.

Поэтому ключ цели ad_logon заводится RSA-2048. Остальные цели Alatyr остаются на ECDSA.

Отдельно то же касается клиента RDP под Linux: freerdp3 версии 3.10.3 ищет на карте только RSA, и с ключом ECDSA перечисление отвечает «0 объектов» при исправной карте и принятом PIN. На более новых сборках FreeRDP вход по ключу ECDSA проходит — но минидрайвер Windows это не отменяет.

Вход — только в Windows

  • Локальный вход по карте не поддерживается намеренно. Вход по карте считается двухфакторным: «что имею» — карта, «что знаю» — PIN. У карты Alatyr ключ неизвлекаемый и привязан к этой же машине, поэтому при локальном входе фактор «что имею» вырождается: человек уже сидит за машиной, где лежит ключ. Остаётся один PIN, и он слабее пароля. В RDP тот же ключ фактором быть не перестаёт: клиентская машина — отдельная вещь от цели.
  • Linux и macOS — только клиенты. С них можно войти на удалённый рабочий стол Windows; локального входа в саму систему по карте Alatyr не даёт.
  • macOS требует особого клиента RDP. В FreeRDP поддержка Kerberos на macOS выключена по умолчанию в самом проекте, поэтому ни один готовый клиент — ни штатный, ни Thincast, ни сборка из Homebrew — войти по карте не может, хотя все они видят считыватель и пробрасывают карту. Чем доставлять сотрудникам клиент с Kerberos, у продукта готового ответа нет.

Автопродления у этой цели нет

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

В день, когда сертификат истечёт, вход по карте перестанет работать сам собой и сам собой не починится. Нужен человек за этой машиной: предъявить PIN кнопкой в окне агента или командой alatyr-agent card-unlock, после чего выдача пройдёт. Планируйте продление заранее, а не по факту отказа.

Агент напоминает об этом сам: заранее, за сутки и после истечения — по одному разу на ступень, с кнопкой «Предъявить PIN».

Того же PIN не требуют две другие вещи: поднять карту (агент поднимает её сам) и сам вход — там PIN спрашивает Windows своим диалогом и проверяет карта. PIN агенту нужен ровно в одном месте — при выдаче сертификата.

Настройку доверия в лесу AD делает администратор

Сертификат на карту агент доводит сам: поднимает смарт-карту, кладёт на неё одобренный сертификат, а штатная служба Windows связывает его с картой — ручных шагов в выдаче нет. Разовой настройкой остаётся доверие в лесу AD. Это раскрытое ограничение — см. Известные ограничения.

Заявка всегда одобряется человеком

По умолчанию заявку на «Вход в AD» одобряет человек: сервисному аккаунту разрешены только те цели, которые ему явно открыли, и в умолчании там один wifi.

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

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

card-prepare снимает вопрос Alatyr, а не диалог PIN у Windows

Вопроса два, и они разные:

Вопрос Кто задаёт Снимает ли card-prepare
подтверждение владельца — гейт присутствия Alatyr агент да, на заданный срок
PIN карты в окне Windows Security Windows нет, и не должен

PIN — фактор «что знаю», он и есть вторая половина двухфакторности. Windows спрашивает его своим диалогом на защищённом рабочем столе, и подавлять это продукт не пытается. Наблюдение «PIN всё равно спрашивают» — ожидаемое поведение, а не дефект.

Подтверждение владельца держится ограниченное время

После предъявления PIN карта примерно две минуты отвечает «владелец подтверждён» и подписывает без нового вопроса всему, что до неё дотянется, — и сеансу, в который вошли, и любому процессу на машине, где стоит считыватель.

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

Пять попыток PIN, и на нуле ключ уничтожается

Счётчик попыток принадлежит карте. На нуле ключ уничтожается необратимо, а вместе с ним обесценивается и выданный сертификат — потребуется новый ключ и новая выдача. Поэтому PIN нигде не зашивается.

card-set-pin выполняется один раз на карту: ключ создаётся под этим PIN, и перезадать его «начисто» нельзя — это оставило бы выданный сертификат без своего ключа.

Подтверждение отпечатком вместо цифр решается один раз

У ключа карты может быть два равных входа: PIN человека и жест Windows Hello (отпечаток, лицо или системный PIN). Оба проверяет чип; ни файла, ни хранимого секрета при этом не появляется.

'<PIN>' | & alatyr-agent.exe card-set-pin --with-gesture
& alatyr-agent.exe card-gesture-probe --pin <PIN>   # проверить, что оба входа живы

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

Чего жест не делает: он не поднимает требования — PIN у такого ключа по-прежнему открывает его один, то есть это второй равный способ, а не замок сверху. И его нет там, где нет окна: на экране входа Windows жеста не спросить ни у кого, поэтому вход по карте идёт PIN'ом всегда. Практически жест закрывает то, с чем человек сталкивается ежедневно, — выдачу и разблокировку из окна агента.

Если Windows Hello на машине не заведён, команда откажет и назовёт это причиной.

На одной карте два сертификата, и это нормально

С одной картой работают две цели: вход в домен и пользовательский mTLS. Считыватель у устройства один, поэтому двумя картами Windows вторую цель не увидела бы вовсе.

certutil -silent -scinfo
Контейнер Сертификат Цель
подписной UPN и SID в SAN вход в домен
обменный адрес в SAN как RFC822 mTLS пользователя

Ключ у них один физически, поэтому открытый ключ у обоих сертификатов совпадает побайтово, а PIN общий. Отсюда два следствия:

  • CurrentUser\My покажет два сертификата с одинаковым открытым ключом. Различать цели по ключу нельзя — только по SAN.
  • Подписной контейнер не кэширует PIN: это требование минидрайвера, а не настройка Alatyr.

Что видно человеку в плитке входа

Windows рисует карту в списке способов входа тремя строками: отображаемое имя, UPN и Smart card credential.

Что Где живёт Кто заполняет Если пусто
Отображаемое имя атрибут displayName учётной записи в AD администратор домена в плитке останется UPN; вход работает
UPN атрибут userPrincipalName администратор домена заявка не подаётся вовсе
SID objectSid берётся из сессии либо из каталога через сервер сертификат выдастся, но вход в домен по нему не пройдёт

Найти учётные записи без отображаемого имени:

Get-ADUser -Filter * -Properties displayName |
  Where-Object { -not $_.displayName } |
  Select-Object SamAccountName, UserPrincipalName

Уже выданные сертификаты не меняются. Имя — часть подписанного сертификата, и переписать его нельзя: плитка станет правильной у тех, кому сертификат перевыпустят. Заставлять перевыпуск ради этого не нужно — на строгое сопоставление имя не влияет никак, каталог сверяет UPN и SID.

На машине вне домена SID приходит из каталога

У локальной учётной записи SID машинный, домену неизвестный, а на macOS такого источника нет вовсе. Поэтому цепочку замыкает сервер Alatyr: он разрешает личность в SID через каталог — если каталог ему настроен (шаг 5 настройки).

Из этого следуют два предела:

  • Каталог не настроен — недоменные машины получат сертификат без SID: годный для mTLS и для проброса в RDP, но не для входа в домен.
  • Человек, о котором система ещё ничего не знает, получит первый сертификат тоже без SID. Сервер отвечает про SID не про кого угодно: иначе обладатель токена одного устройства получил бы справочник по всему каталогу. Вход открывает выписанное задание: администратор называет человека и машину, после чего следующий сертификат будет полноценным.

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

Что дальше

  • Настройка — вернуться к пошаговому порядку: домен, админка, устройство.
  • Вход по RDP — подключение с Windows, Linux и Mac и подготовка машины-цели.
  • Известные ограничения — пределы всего продукта, не только этого раздела.