OOOps... There is one thing I don't understand : normally, pkinit is generated automatically when you run configure (only disable-pkinit is offered as an option).... In my case, the sources are here, but no object file is generated by Makefiles. Isn't some piece missing (I run krb 1.8.3).
Thxs P On 04/04/2011 17:52, Kevin Coffman wrote: I don't see any attempt at initializing pkinit. Is the plugin there? On Mon, Apr 4, 2011 at 11:39 AM, JAKOBI Pascal <pascal.jak...@thalesgroup.com><mailto:pascal.jak...@thalesgroup.com> wrote: > Here you go... > > > [root@serveur sbin]# ./krb5kdc -n > stat(/usr/local/lib/krb5/plugins/kdb/db2): No such file or directory > get_plugin_data_sym(kdb_function_table) > get_plugin_data_sym(preauthentication_server_1) > get_plugin_data_sym(authdata_server_2) > get_plugin_data_sym(authdata_server_0) > 0x9375ff0={ > name=lo > flags=10049<UP,LOOPBACK,RUNNING> > addr=0x937600c <getnameinfo error -6: ai_family not supported> family=17 > broadaddr=0x9376054 <getnameinfo error -6: ai_family not supported> > family=17 > dstaddr=0x9376054 <getnameinfo error -6: ai_family not supported> > family=17 > data=0x9376434 > } > 0x937608c={ > name=eth0 > flags=11043<UP,BROADCAST,RUNNING,MULTICAST> > addr=0x93760a8 <getnameinfo error -6: ai_family not supported> family=17 > broadaddr=0x93760f0 <getnameinfo error -6: ai_family not supported> > family=17 > dstaddr=0x93760f0 <getnameinfo error -6: ai_family not supported> > family=17 > data=0x9376490 > } > 0x9376128={ > name=wlan0 > flags=1003<UP,BROADCAST,MULTICAST> > addr=0x9376144 <getnameinfo error -6: ai_family not supported> family=17 > broadaddr=0x937618c <getnameinfo error -6: ai_family not supported> > family=17 > dstaddr=0x937618c <getnameinfo error -6: ai_family not supported> > family=17 > data=0x93764ec > } > 0x93761c4={ > name=lo > flags=10049<UP,LOOPBACK,RUNNING> > addr=0x93761e0 127.0.0.1 > netmask=0x9376204 255.0.0.0 > broadaddr=0x9376228 127.0.0.1 > dstaddr=0x9376228 127.0.0.1 > } > 0x9376260={ > name=eth0 > flags=11043<UP,BROADCAST,RUNNING,MULTICAST> > addr=0x937627c 10.222.144.38 > netmask=0x93762a0 255.255.254.0 > broadaddr=0x93762c4 10.222.145.255 > dstaddr=0x93762c4 10.222.145.255 > } > 0x93762fc={ > name=lo > flags=10049<UP,LOOPBACK,RUNNING> > addr=0x9376318 ::1 > netmask=0x937633c ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff > } > 0x9376398={ > name=eth0 > flags=11043<UP,BROADCAST,RUNNING,MULTICAST> > addr=0x93763b4 fe80::20f:1fff:feba:2e13%eth0 > netmask=0x93763d8 ffff:ffff:ffff:ffff:: > } > krb5kdc: starting... > > > On 04/04/2011 17:34, Kevin Coffman wrote: > > It doesn't appear that the KDC is offering PKINIT as a > pre-authentication option (pa_types 15,16,17,18). I believe the KDC's > certificate looks OK, but there are other things required in the KDC's > configuration before it will offer PKINIT. (i.e. the plugin must be > available, and initialize properly.) Do you have debug output from > the KDC's [plugin] initialization? > > > On Mon, Apr 4, 2011 at 11:14 AM, JAKOBI Pascal > <pascal.jak...@thalesgroup.com><mailto:pascal.jak...@thalesgroup.com> wrote: >> Kevin >> >> It took me a while to get back to the issue. Apologies for this. >> Essentially, here is what I get when running kinit with "DEBUG" set. >> >> ./kinit -X X509_user_identity='/C=FR/O=BioNet/CN=user/' >> u...@bionet.fr<mailto:u...@bionet.fr> >> get_plugin_data_sym(preauthentication_client_1) >> init module "Encrypted Challenge", pa_type 138, flag 1 >> get_plugin_data_sym(service_locator) >> get_plugin_data_sym(service_locator) >> get_plugin_data_sym(service_locator) >> preauth data types before sorting: 2 136 19 13 133 >> preauth data types after sorting: 2 136 19 13 133 >> salt len=-1; preauth data types: 2 136 19 13 133 >> trying modules for pa_type 2, flag 2 >> trying modules for pa_type 136, flag 2 >> etype info 0: etype 18 salt len=-1 >> etype info 1: etype 17 salt len=-1 >> etype info 2: etype 16 salt len=-1 >> etype info 3: etype 23 salt len=-1 >> trying modules for pa_type 19, flag 2 >> trying modules for pa_type 13, flag 2 >> calling internal function for pa_type 133, flag 2 >> trying modules for pa_type 133, flag 2 >> calling internal function for pa_type 2, flag 1 >> preauth2.c:708: salt len=-1; *etype=18 request->ktype[0]=18 >> Password for u...@bionet.fr:<mailto:u...@bionet.fr:> >> key type 18 bytes a3 27 ... >> enc data { type=18 kvno=0 data=fd 91 ... } >> get_plugin_data_sym(service_locator) >> get_plugin_data_sym(service_locator) >> get_plugin_data_sym(service_locator) >> preauth data types before sorting: 19 >> preauth data types after sorting: 19 >> salt len=-1; preauth data types: 19 >> etype info 0: etype 18 salt len=-1 >> trying modules for pa_type 19, flag 2 >> [root@client bin]# >> >> Attached are a bunch of information that may help. >> >> Thanks again for your help. >> P >> >> >> >> On 31/03/2011 16:44, Kevin Coffman wrote: >> >> On Thu, Mar 31, 2011 at 7:28 AM, JAKOBI Pascal >> <pascal.jak...@thalesgroup.com><mailto:pascal.jak...@thalesgroup.com> wrote: >>> Hi there >>> >>> I need help in order to get PKINIT working on Fedora 14. >>> I have a running kerberos server with krb-server, krb-server-ldap and so >>> on (1.8.2). >>> I also have installed krb5-pkinit-openssl. >>> >>> The stuff works like a charm when running in "standard" kerberos, i.e. >>> w/o pkinit. >>> >>> Then we tried to set up pkinit according to the instructions found at >>> http://k5wiki.kerberos.org. In particular, we checked carefully, our >>> certs. >> >> Perhaps you could list your certificate information here for both the >> user and KDC certificates (the output of "openssl x509 -noout -text >> -in YOUR.CRT"). >> >>> However, the behaviour does not seem correct. >>> >>> We issue a kinit -X x509_user_identity=<DN found in the client cert> >>> <principal> on the client side (another Fedora instance with software >>> certs). >>> With Wireshark, we see that an AS-REQ is sent to the server. However, it >>> does not seem to convey any certificate (pa-data type = 149). >>> >>> Then the server replies with ERR_PREAUTH_REQUIRED (the principal that is >>> used has its preauth option set). Is this normal ? >> >> This is normal. If the KDC's pkinit preauth plugin is properly >> configured (valid certificate and kdc.conf configuration options), one >> of the preauth options it should return is PKINIT. (14,15,16, or 17) >> The client should then send the PKINIT preauth information in its >> subsequent request. If it is accepted by the KDC, there shouldn't be >> a pasword prompt. >> >>> As a result of this, the standard AS_REQ/REP procedure seems to be >>> played (as a password is requested on the client side). >>> >>> The problem is that even when recompiling pkinit with DEBUG set, we >>> cannot see anything.... >> >> Are you running your KDC in the foreground? Debug output will go to >> stderr or stdout. Verify that the PKINIT preauth plugin is >> successfully loaded and properly initialized. >> >>> Any help (very) greatly appreciated. >>> >>> Thanks >>> Pascal >>> >>> -- >>> Pascal Jakobi >>> Sr. Architect, Thales >>> 1 av. A. Fresnel >>> 91767 Palaiseau, France >>> Tel. : +33 1 69 41 60 51 >>> Mob.: + 33 6 87 47 58 19 >>> >>> ________________________________________________ >>> Kerberos mailing list Kerberos@mit.edu<mailto:Kerberos@mit.edu> >>> https://mailman.mit.edu/mailman/listinfo/kerberos >>> >> >> . >> >> -- >> Pascal Jakobi >> Sr. Architect, Thales >> 1 av. A. Fresnel >> 91767 Palaiseau, France >> Tel. : +33 1 69 41 60 51 >> Mob.: + 33 6 87 47 58 19 >> > > . > > -- > Pascal Jakobi > Sr. Architect, Thales > 1 av. A. Fresnel > 91767 Palaiseau, France > Tel. : +33 1 69 41 60 51 > Mob.: + 33 6 87 47 58 19 > . -- Pascal Jakobi Sr. Architect, Thales 1 av. A. Fresnel 91767 Palaiseau, France Tel. : +33 1 69 41 60 51 Mob.: + 33 6 87 47 58 19 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos