Tryag File Manager

//proc/self/root/usr/share/doc/pkinit-nss-0.7.6/README

1. Requirements for the KDC's certificate.
   The KDC certificate must contain a subjectAltName extension value of
   type id-pkinit-san (see RFC4556) with your realm's ticket granting
   service's name as its value, for example
      krbtgt/EXAMPLE.COM@EXAMPLE.COM
   The certificate and its matching key are expected to be found in the
   NSS database stored in the server's default location, which by
   default is /var/kerberos/krb5kdc.

2. Requirements for the client's certificate.
   The user's certificate should contain a subjectAltName extension
   value of type id-pkinit-san (see RFC4556) with your user's principal
   name as its value, for example
      jimbo@EXAMPLE.COM
   Alternatively, it can contain both a subjectAltName extension value
   of type id-ms-san-sc-logon-upn (see RFC4556) containing the user's
   principal name as its value AND an extendedKeyUsage extension
   containing id-ms-kp-sc-logon (see RFC4556) as a value.

3. More KDC requirements.
   The KDC must trust the user's certificate.  That means that its NSS
   database, which by default is in /var/kerberos/krb5kdc, must include
   a CA certificate in the client's signing chain, and it must be
   configured to trust that certificate.

4. More client requirements.
   The client system must trust the KDC's certificate.  That means that
   its NSS database, which by default is in /etc/pki/nssdb, must include
   a CA certificate in the KDC's signing chain, and it must be
   configured to trust that certificate.

If the KDC is a Windows domain controller, it will not contain either
   a id-pkinit-san or id-ms-san-sc-logon-upn value in its subjectAltName
   extension, but it will include the server's GUID as a value.  It will
   usually also contain a CertificateTemplate extension containing the
   value "DomainController".  In this case the implementation can use
   the certificate template information and check for the domain
   controller's GUID in a list which is configured in krb5.conf like so:

[appdefaults]
     pkinit = {
       # Trust "9a:37:dd:c9:ad:15:34:4e:9d:36:b4:9f:fd:91:b8:73" no
       # matter which realm.
       trusted_guid = 9a:37:dd:c9:ad:15:34:4e:9d:36:b4:9f:fd:91:b8:73
       BOSTON.REDHAT.COM = {
         # Trust "9a:37:dd:c9:ad:15:34:4e:9d:36:b4:9f:fd:91:b8:74" and
	 # "9a:37:dd:c9:ad:15:34:4e:9d:36:b4:9f:fd:91:b8:75" for just
	 # this realm.
         trusted_guid = 9a:37:dd:c9:ad:15:34:4e:9d:36:b4:9f:fd:91:b8:74 9a:37:dd:c9:ad:15:34:4e:9d:36:b4:9f:fd:91:b8:75
       }
     }

If you don't know your domain controller's GUID, you can extract it
   from a copy of its certificate using the "pkinit-show-cert-guid"
   command.

Alternatively, the "pkinit_kdc_hostname" and "pkinit_eku_checking"
   settings can be used to specify an acceptable combination of DNS
   server names and extendedKeyUsage values ("kpKDC", "kpServerAuth",
   "none").

[appdefaults]
     pkinit = {
       pkinit_kdc_hostname = kdc1.example.com
       pkinit_eku_checking = kpServerAuth
     }