CRT-UT

The syntax of this command is:

CRT-UT [ v0 | v1 | v2 | v3 | v4 ]

	v0: *user*[UserName]*pfx-file-name*pass-for-pfx
	v1: *ea
	v2: *kdc
	v3: *export*sst-file-name
	v4: *import*sst-file-name

output info to console or file. in case file - in UTF-8 encoding

*user*[UserName]*pfx-file-name*pass-for-pfx

create certificate from "SmartcardLogon" template and store it with private key to in PFX (P12) format with

the private key created in memory and stored only in selected PFX. never, even temporary, not stored on disk

in case UserName is empty - certificate created for the current user

user must be in (Domain/Built-in) Administrators group ( if used default/not modified SmartcardLogon" template security )

example:

CRT-UT.exe *user**admin.pfx*1234*abcd

certificate (+ private key) for current user will be stored in admin.pfx with 1234*abcd password

in case user name not empty, the Enroll On Behalf Of (EOBO) request will be used for create cert for UserName current user must be admin and must already have EnrollmentAgent certificate in MY store

the UserName can be fully qualified account name (for example, DomainName\UserName) or isolated name (for example, UserName)

Fully qualified names are unambiguous and provide better performance when the lookup is performed. also supported fully qualified DNS names (for example, Example.Example.com\UserName) and user principal names (UPN) (for example, Someone@Example.com).

Translation of isolated names introduces the possibility of name collisions ( say you have domain and local user with the same name)

you can view cert from pfx file with PFXviewer.exe - this tool work only in memory. never, even temporary, not put cert/key int containers you can write pfx to virtual smart card by using SCV1.exe or SCV2.exe

SCV1.exe using removable disk as container for smart card. so you can write it once and then use many time SCV2.exe using ephemeral (in memory only) smart cards, in case you do not require access to persisted SC (you can use both SCv1 and SCv2 on same comp)

*ea

create certificate from "EnrollmentAgent" template and put it to current user "My" store private key stored under current user CNG key store and marked as exportable

*kdc

create certificate from "KerberosAuthentication" template and put it to local machine "My" store private key stored under local machine CNG key store and marked as exportable The local machine must be a Kerberos KDC (domain controller)

*export*sst-file-name

store cerificates chanin for current kdc cert in . also save here fully-qualified DNS name of current machine this information need be installe at not current domain joined comp, for login via smart card/certificate The local machine must be a Kerberos KDC (domain controller)

*import*sst-file-name

generated by exportsst-file-name must be runned on not domain joined comp add cerificates from to Intermediate CA (if exist more than 1 in chain) and last to Trusted Root CA also first cert in chain added to NTAuth store

the key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains<fullDomainDnsName> is created

	<fullDomainDnsName>: KdcNames REG_MULTI_SZ <KDCcomputerName.fullDomainDnsName>

computer must be able resolve <KDCcomputerName.fullDomainDnsName> to ip

(add it to hosts ? )

typical usage:

ensure that you have certificate with "KDC Authentication" EKU in Local Machine MY store

if not - you can request this certificate from mmc/cerificates snap-in or use *kdc command

ensure that you have certificate with "Certificate Request Agent" EKU in current user MY store

if not - use *ea or mmc/cerificates snap-in

create certificates for user(s) with user...
in case you need RDP login from not domain joined comp - save (from KDC comp) certificate chain context starting from KDC certificate issuer ( usually this is single cert chain ) in sst file

exportmy.sst

and import it on client comp ( importmy.sst )