Help using PKINIT (MIT)
JAKOBI Pascal
pascal.jakobi at thalesgroup.com
Mon Apr 4 12:00:39 EDT 2011
This should be the issue....
I did not do a configure with "enable-pkinit". Let me check this and come back to you (tomorrow).
Thanks again for your great help.
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.jakobi at thalesgroup.com><mailto:pascal.jakobi at thalesgroup.com> wrote:
> Here you go...
>
>
> [root at 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.jakobi at thalesgroup.com><mailto:pascal.jakobi at 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/' user at BIONET.FR<mailto:user at 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 user at BIONET.FR:<mailto:user at 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 at 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.jakobi at thalesgroup.com><mailto:pascal.jakobi at 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 at mit.edu<mailto:Kerberos at 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
More information about the Kerberos
mailing list