Smart-card (PIV) console login

Bind an admin’s PIV hardware token to their directory identity and let them sign in to the console with the card plus a PIN — strong, phishing-resistant MFA instead of a password. This is proven today as a Windows operator flow: the card’s certificate is mapped to the AD user by a strong issuer + serial binding, the reader driver is deployed for you, and login happens at the physical console session.

What you need #

1. Bind the card to an admin identity #

Open the console’s /access → PIV tab and step through issuance there: pick the AD user, run the on-card request, then Skans signs the certificate from the built-in Skans Root CA, registers it, and binds it to that user.

The binding is what makes this strong. Skans sets the AD user’s altSecurityIdentities to the certificate’s issuer + serial (KB5014754 strong mapping). At login the console resolves that strong binding first, and only falls back to the certificate’s UPN if no strong binding exists.

2. The reader driver is deployed for you #

On Windows the in-box Microsoft CCID/PIV driver enumerates the reader but never registers this token’s ATR, so Windows can’t actually read the card. The vendor uTrust minidriver (utrustmd.dll) is required.

You don’t install it by hand. The Skans agent handles it (EnsureUTrustMinidriver): it pulls a hash-pinned vendor installer from NETLOGON\SkansAgent\drivers, runs it silently as SYSTEM into the Windows driver store, and Windows binds it on the first card insert.

TEXTCopy
Agent  →  pull hash-pinned minidriver from NETLOGON\SkansAgent\drivers
       →  install /S as SYSTEM into the driver store
       →  Windows binds utrustmd.dll on first card insert   (no field-user install)

3. Log in from the console session #

Insert the card at the appliance’s physical console and go to /login/cert. The endpoint does mutual-TLS client-certificate authentication together with the card PIN. On success you’re signed in as the mapped AD user, with the authentication method recorded as smartcard.

TEXTCopy
Card inserted  →  /login/cert  (mTLS client cert + card PIN)
               →  strong issuer + serial match to the AD user
               →  signed in as that user   (method = smartcard)

Proven end to end: the card signs in as AD user david, method=smartcard, with the Admin role.

Why it must be the console session #

The PIV reader is invisible to RDP and other non-console sessions. Establishing a smart-card context succeeds as SYSTEM (session 0) but fails as an RDP user with SCARD_E_NO_SERVICE (“Smart Card Resource Manager not running”):

TEXTCopy
SCardEstablishContext  as SYSTEM (session 0)  →  OK
SCardEstablishContext  as RDP user            →  SCARD_E_NO_SERVICE

Platform support #

• Windows — supported. Proven from the physical console session with the auto-deployed minidriver, as above.
• Linux — manual, not an operator flow. PIV was proven on Linux only via a manual per-machine setup (loading the OpenSC PKCS#11 module into the browser’s NSS database). Browser login does not work until that module is loaded, and there is no auto-config agent for Linux. Don’t hand this to a field user.
• iPhone / iOS — not supported for PIV. iOS has no PC/SC stack, so the PIV side doesn’t work. The realistic iOS path is the token’s FIDO2 side — which is itself not yet hardware-tested (see below).
• macOS — untested.

Coming soon: driver-free FIDO2 / WebAuthn #

FIPS posture — be precise #

Next #

• Roles & RBAC → — the role the card’s identity lands in
• Manage credentials → — the vault that holds the card’s management key
• Install & approve the Windows agent → — the agent that auto-deploys the reader minidriver
• Troubleshooting → — reader not detected, and the RDP-vs-console gotcha