The Windows KCA service can be downloaded (ZIP). [Refreshed 20080508]
Changes in the 20080508 build:
Changes in the 20080507 build:
Changes in the 20080417 build:
Changes in the 20080416 build:
Changes in the 20080402 build:
Changes in the 20080327 build:
Changes in the 20080318 build:
The service consists of kca_service.exe and a pthreads dll. Place them into your desired directory, for example C:\KCA. The service requires that Kerberos for Windows be installed.
Copy into the same directory the following files:
Once these files are in place, execute "kca_service -i" to register "kcaservice" as an auto-start service. "kca_service -u" will deregister it.
You can test the service without registering it by executing it from the command line.
The following registry values are supported:
"Threaded" REG_DWORD [can be 0 or 1]
"ConfigFile" REG_SZ [path to the kca.cnf file]
These values will be created automatically when installed. When the values are not present the process runs in a single thread mode and looks for "kca.cnf" in the same directory as kca_service.exe.
This service can be installed on any machine in the domain. It does not require that it be run on a domain controller. It does not use LDAP to query the domain controller.
Each instance of the service should have a separate "user" account defined in the domain. Once the account is created, the following ktpass command can be used as a template for configuring it and generating the keytab file. I used an account named "kca_service" in the WINDOWS.SECURE-ENDPOINTS.COM domain and installed the service on a machine named galatea.windows.secure-endpoints.com.
[D:\]ktpass /out kca_service.keytab /mapuser kca_service@WINDOWS.SECURE-ENDPOINTS.COM /pass <Password> /princ kca_service/galatea.windows.secure-endpoints.com@WINDOWS.SECURE-ENDPOINTS.COM /DesOnly /mapOp add /crypto DES-CBC-CRC /ptype KRB5_NT_SRV_HST
The output should look something like this:
Targeting domain controller: dc.windows.secure-endpoints.com Successfully mapped kca_service/galatea.windows.secure-endpoints.com to kca_service. Key created. Output keytab to kca_service.keytab: Keytab version: 0x502 keysize 104 kca_service/galatea.windows.secure-endpoints.com@WINDOWS.SECURE-ENDPOINTS.COM ptype 3 (KRB5_NT_SRV_HST) vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0x525db5b3c707b51a) Account kca_service has been set for DES-only encryption.
The "user" account in Active Directory should have the NO_AUTH_REQUIRED flag set in the UserAccountControl property.
As with the existing KCA service on UNIX, DNS SRV records can be added to the domain to publish their locations to clients. The service is multi-threaded requires about 6MB of RAM, and is very low impact. CPU utilization on a Pentium III domain controller rarely exceeds single digit percentages while processing certificate requests. Unlike the UNIX KCA service, this version does not have the added complexity of LDAP queries. All requests to obtain the Display Name from the Kerberos Principal are performed with the TranslateName API. This avoids all of the overhead associated with managing a separate pool of threads for LDAP queries and the additional layer of complexity associated with performing SASL-GSS-Kerberosv5 authentication from within the OpenLDAP library. With the Windows KCA, the Kerberos v5 keytab is only used to authenticate the incoming client requests. There is no need to periodically renew service tickets in the background.
The service has undergone stress testing. With five worker threads the service was able to issue ~100,000 certificates to 40 clients in six hours on a dual processor Pentium III Windows Server 2003 system.
The standard KCA port is 9878/UDP. The Windows Firewall must be configured to provide access to this port.
The [kx509] section of the OpenSSL configuration file
There are several options that can be set in the [kx509] section to control the behavior of the kca service.
keytab = <file>. The default is to use "kca_service.keytab" located in the same directory as the service executable.
krb5_use_rcache = "yes"|"no". The default is "yes". Setting to no disables the use of the Kerberos v5 replay cache. The replay cache is created in the %TEMP% or %TMP% directory.
min_threads = <number>. The default is 5. This value determines the initial number of worker threads created when the service starts.
max_threads = <number>. The default is 20. This value determines the maximum number of worker threads that can be created as needed in order to serve incoming requests.
soft_timeout = <seconds>. The default is 1. This value determines how long the service will block processing incoming requests when all worker threads are busy processing certificate requests.
cancel_timeout = <seconds>. The default is . This value determines how long the service will wait before determining that worker threads have died and should be reborn.
hard_timeout = <seconds>. The default is 24. This value determines how long the service will wait before sending a busy error to the caller.
server_port = <number>. The default is 9878. This value determines which UDP port number the service listens for requests on. This value should not be set without understanding the consequences.
krb5_authorized_realm_<n> = Defines a client realm that the KCA service is permitted to issue certificates to. <n> is a sequential number starting with 1. For example, "krb5_authorized_realm_1 = EXAMPLE.COM" and "krb5_authorized_realm_2 = WIN.EXAMPLE.COM".
krb5_translate_realm_<n> = Specifies the realm which when combined with the first component of the authenticated client principal can be used to find a matching user object in the Active Directory database. Typically this will be the Active Directory domain. The value of <n> used must match the value from krb5_authorized_realm_<n>. For example, "krb5_translate_realm_1 = WIN.EXAMPLE.COM".
fail_on_lookup_error = "yes"|"no". The default is "no". Setting to yes prevents the issuance of certificates when the Win32 TranslateName() API fails.
krb5_require_hwauth = "yes"|"no". The defaults is "no". Setting to yes requires that the initial Kerberos ticket granting ticket be obtained using hardware preauthentication.
include_netscape_userid_extension = "yes"|"no". The default is "yes". Setting to yes instructs the KCA to include the Netscape UserID Extension component as part of the Subject Distinguished Name. The included value is the first component of the Kerberos principal name and is only included if the Kerberos principal exists within the Active Directory database.
include_pseudonym = "yes"|"no". The default is "no". Setting to yes instructs the KCA to include the Pseudonym component as part of the Subject Distinguished Name. The included value is the first component of the Kerberos principal name prefixed by the string specified by pseudonym_prefix. It is only included if the Kerberos principal exists within the Active Directory database.
pseudonym_prefix = "<string>". The default is the empty string. This string is combined used as a prefix for the generation of the Pseudonym component of the Subject Distinguished Name.
include_cn_uid = "yes"|"no". The default is "no". Setting to yes instructs the KCA to include a CN component set to the UserID as part of the Subject Distinguished Name. The included value is the first component of the Kerberos principal name prefixed by the string specified by cn_uid_prefix. It is only included if the Kerberos principal exists within the Active Directory database.
cn_uid_prefix = "<string>". The default is the empty string. This string is combined used as a prefix for the generation of the CN UserID component of the Subject Distinguished Name.
fnal_strip_badge_no = "yes"|"no". The default is "no". This option is specific to FermiLab which includes the badge number in the display name of the Active Directory account object but does not wish the badge number to be included in the certificate Subject Distinguished Name.
Changes from the UNIX KCA:
What has not been done:
Issuing Certificates to non-Domain Kerberos principals:
The Windows KCA will only issue certificates to Kerberos principals that are mapped to accounts in Active Directory. When cross-realm associations are in place, a mapping for user@SECURE-ENDPOINTS.COM can be associated with the "user" account in the WINDOWS.SECURE-ENDPOINTS.COM domain. This permits certificates to be issued to either user@SECURE-ENDPOINTS.COM or user@WINDOWS.SECURE-ENDPOINTS.COM.
Using KCA Certs with IIS:
IIS permits client certificates to be mapped to domain accounts. In order to map KCA certificates to domain accounts, use the e-mail field as the mapping key and map the Kerberos principal name that is stored there to the domain account UPN.
KCA Provider for NIM:
For best results, use version 2.1.0.