On Wed, 2009-03-04 at 06:33 -0800, Loren M. Lang wrote: > On Wed, 2009-03-04 at 08:46 -0500, Kevin Coffman wrote: > > On Wed, Mar 4, 2009 at 1:49 AM, Loren M. Lang <[email protected]> > > wrote: > > > I am trying to enable smartcard logins to a MIT Kerberos domain using > > > the recent PK-INIT preauth plugin. I am using Ubuntu 8.10 with it's > > > stock Kerberos 1.6.4 packages except for pkinit.so recompiled with > > > -DDEBUG. I have a server certificate installed on the KDC with the > > > extended key usage id_pkinit_KPKdc and an appropriate subjectAltName. > > > There is one intermediate certificate between it and the root CA. > > > Client certificates were generated similarly only with the > > > id_pkinit_KPClientAuth key usage and have two intermediates between it > > > and the same root CA. The client certificates are installed on a smart > > > card using opensc and are also enabled for the clientAuth key usage for > > > SSL client authentication. I also have intermediate CAs and the root CA > > > installed on the smart card as well. Firefox is able to see the smart > > > card including all intermediates and root CAs and is able to use it to > > > authenticate against a SSL website. Running kinit with debugging output > > > I was able see that is was complaining that the smart card had four > > > matching certs. It did not filter out certificates missing the > > > appropriable key usages or missing subjectAltName, maybe that's typical. > > > I setup a pkinit_cert_match to filter out the other certificates and now > > > kinit reports finding exactly one match, but bails out later due to > > > missing intermediate certificates so I setup pkinit_pool to point > > > to /etc/ssl/certs with appropriate certificates. It did not seem to use > > > the intermediates already on the smart card, is this normal? > > > > Normal is subjective ;-) There is no code to deal with intermediates > > or root CAs that might be found on the smartcard. > > Bad choice of words, I meant, how MIT's PK-INIT code is supposed to > behave. I was assuming that this functionality was supported by > OpenSSL/OpenSC and not MIT specifically. > > > > > > Now kinit > > > was complaining about some broken symlinks that exist > > > under /etc/ssl/certs and it bails out. Shouldn't these just be ignored? > > > > I thought anything that wasn't a cert was ignored w/o bailing, but > > this might have been missed. > > > > > This symlinks point to missing certificates that have nothing to do with > > > the pki infrastructure I am using, but once I moved the symlinks out of > > > the way, kinit continued and finally sent out an AS-REQ with the PK-INIT > > > preauth data, but received no response. According to Wireshark, > > > following the initial AS-REQ with no preauth, the server responds with a > > > NEEDED_PREAUTH error listing six preauth types including PA-PK-AS-REQ > > > and PA-PK-AS-REP. The client then sends a single IP fragment response. > > > The fragment has a payload of 1480 bytes with flag more fragments, but > > > no further fragments are sent. I have no firewall rules installed and > > > am at a loss as to why there are no more fragments. > > > > I'm not sure what might be happening here. This would just be a > > work-around, but is it possible for you to try using TCP rather than > > UDP? > > I enabled TCP support on my KDCs and netstat confirms they are listening > on them. I tried setting udp_preference_limit to 1480, 1000, and 50, > but kinit never uses TCP. I put udp_preference_limit both at the very > beginning and very end of my libdefaults section in krb5.conf and even > tried using copy/paste to double check that I typed it correctly.
Never mind, I was using SRV records and only install _udp types. Specifying the server in krb5.conf resolved that. Now, the error I am getting is KRB5KRB_ERR_GENERIC: KDC_RETURN_PADATA. > > Also, kdc_tcp_ports is not documented in my kdc.conf man page. I had to > look in the info pages for it. > > > > > K.C. > > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos -- Loren M. Lang [email protected] http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B
smime.p7s
Description: S/MIME cryptographic signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
