It sounds like something might be missing. I don't recall the exact build requirements, but it expects openssl to be available. I'm not sure what other failure [to build] scenarios there might be...
On Mon, Apr 4, 2011 at 12:07 PM, JAKOBI Pascal <[email protected]> wrote: > 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 > <[email protected]> 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 >> <[email protected]> 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/' [email protected] >>> 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 [email protected]: >>> 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 >>> <[email protected]> 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 [email protected] >>>> 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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
