kdb5_util dump and load questions - Kerberos

This is a discussion on kdb5_util dump and load questions - Kerberos ; I did a kdb5_util dump and a kdb5_util dump -ov from Kerberos 5 version 1.4.1, the -ov option generates some warnings: [root@s1 krb5kdc]# kdb5_util dump s1-old-kdb-dump [root@s1 krb5kdc]# kdb5_util dump -ov s1-old-kdb-dump.ov Warning! No DES-CBC-CRC key for principal testua@DEVMINES.EDU , ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: kdb5_util dump and load questions

  1. kdb5_util dump and load questions

    I did a kdb5_util dump and a kdb5_util dump -ov from Kerberos 5 version
    1.4.1, the -ov option generates some warnings:

    [root@s1 krb5kdc]# kdb5_util dump s1-old-kdb-dump
    [root@s1 krb5kdc]# kdb5_util dump -ov s1-old-kdb-dump.ov
    Warning! No DES-CBC-CRC key for principal testua@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    Warning! No DES-CBC-CRC key for principal testua@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    Warning! No DES-CBC-CRC key for principal testuc@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    Warning! No DES-CBC-CRC key for principal testuc@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    Warning! No DES-CBC-CRC key for principal testud@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    Warning! No DES-CBC-CRC key for principal testuf@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    Warning! No DES-CBC-CRC key for principal testuf@DEVMINES.EDU, cannot
    generate OV-compatible record; skipping
    [root@s1 krb5kdc]#

    When I try to import the file into Kerberos 5 version 1.5.2 I get more
    messages:

    [root@s1 krb5kdc]# kdb5_util load s1-old-kdb-dump
    [root@s1 krb5kdc]# kdb5_util load -update s1-old-kdb-dump.ov
    (null): Unknown code imp 4 testua@DEVMINES.EDU
    (null): Unknown code imp 4 testua@DEVMINES.EDU
    (null): Unknown code imp 4 testuc@DEVMINES.EDU
    (null): Unknown code imp 4 testuc@DEVMINES.EDU
    (null): Unknown code imp 4 testud@DEVMINES.EDU
    (null): Unknown code imp 4 testuf@DEVMINES.EDU
    (null): Unknown code imp 4 testuf@DEVMINES.EDU
    [root@sixoften krb5kdc]#

    What do the warnings from the dump mean?

    Also, what does the corresponding error from the load mean?

    There are other principals in the kdc that do not generate any warnings
    or errors. In kadmin the the principals look fine after the load.
    Unfortunately, I do not have passwords for these principals.

    Thank You.

    Matt
    mbrookov@mines.edu


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. kadmin.local and kadmind dump core, was Re: kdb5_util dump andload questions

    It seems that you get these DES-CBC-CRC warnings on a principal that has
    had its password changed. There is 1 warning for every old password
    that is kept in the database. Also, some of the principals are not able
    to log in:

    [root@sixoften krb5kdc]# kinit testub@DEVMINES.EDU
    Password for testub@DEVMINES.EDU:
    kinit(v5): Password incorrect while getting initial credentials
    [root@sixoften krb5kdc]#


    If I use cpw in kadmin to change the password kadmind on the kdc stops
    running. I stopped krb5kdc and ran kadmin.local, and tried cpw again,
    kerbers 5 version 1.4.1 and version 1.5.2 both segmentation fault in a
    function named check_pw_reuse:


    [root@sixoften krb5kdc]# kadmin.local
    Authenticating as principal mbrookov/admin@DEVMINES.EDU with password.
    kadmin.local: cpw testub
    Enter password for principal "testub":
    Re-enter password for principal "testub":
    Segmentation fault (core dumped)
    [root@sixoften krb5kdc]#


    Out of curiosity I dumped the database, wiped it out, and reloaded it
    and got the same core dump. I also loaded the dump from 1.4.1 into
    version 1.5.2 and check_pw_reuse dumped core at the same line. This
    suggests to me that the file is not corrupt.

    It looks to me like kadmin dumps core because histkey.contents is null,
    see below for GDB output. This patch will work around the seg fault:


    [mbrookov@sixoften src]$ diff -c ./lib/kadm5/srv/svr_principal.c.20070411 ./lib/kadm5/srv/svr_principal.c
    *** ./lib/kadm5/srv/svr_principal.c.20070411 2007-04-11 16:10:56.000000000 -0600
    --- ./lib/kadm5/srv/svr_principal.c 2007-04-11 16:11:42.000000000 -0600
    ***************
    *** 954,959 ****
    --- 954,960 ----

    if ((newkey.length == histkey.length) &&
    (newkey.enctype == histkey.enctype) &&
    + histkey.contents != 0 &&
    (memcmp(newkey.contents, histkey.contents,
    histkey.length) == 0)) {
    krb5_free_keyblock_contents(context, &histkey);
    [mbrookov@sixoften src]$

    The patch is for svr_principal.c in Kerberos 5 version 1.5.2. I do not
    believe this patch is the right solution, it does not explain why
    histkey.contents is null.

    FYI, here is the gdb output for kadmin.local from kerbers 5 version
    1.5.2:

    [root@sixoften krb-backup]# gdb /usr/local/sbin/kadmin.local core.4269
    GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db lib rary "/lib/tls/libthread_db.so.1".

    Core was generated by `kadmin.local'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /usr/local/lib/libkadm5srv.so.5...done.
    Loaded symbols for /usr/local/lib/libkadm5srv.so.5
    Reading symbols from /usr/local/lib/libkdb5.so.4...done.
    Loaded symbols for /usr/local/lib/libkdb5.so.4
    Reading symbols from /usr/local/lib/libgssrpc.so.4...done.
    Loaded symbols for /usr/local/lib/libgssrpc.so.4
    Reading symbols from /usr/local/lib/libgssapi_krb5.so.2...done.
    Loaded symbols for /usr/local/lib/libgssapi_krb5.so.2
    Reading symbols from /lib/libdl.so.2...done.
    Loaded symbols for /lib/libdl.so.2
    Reading symbols from /usr/local/lib/libkrb5.so.3...done.
    Loaded symbols for /usr/local/lib/libkrb5.so.3
    Reading symbols from /usr/local/lib/libk5crypto.so.3...done.
    Loaded symbols for /usr/local/lib/libk5crypto.so.3
    Reading symbols from /usr/local/lib/libcom_err.so.3...done.
    Loaded symbols for /usr/local/lib/libcom_err.so.3
    Reading symbols from /usr/local/lib/libkrb5support.so.0...done.
    Loaded symbols for /usr/local/lib/libkrb5support.so.0
    Reading symbols from /lib/libresolv.so.2...done.
    Loaded symbols for /lib/libresolv.so.2
    Reading symbols from /lib/tls/libpthread.so.0...done.
    Loaded symbols for /lib/tls/libpthread.so.0
    Reading symbols from /lib/tls/libc.so.6...done.
    Loaded symbols for /lib/tls/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...done.
    Loaded symbols for /lib/ld-linux.so.2
    Reading symbols from /usr/local/lib/krb5/plugins/kdb/db2.so...done.
    Loaded symbols for /usr/local/lib/krb5/plugins/kdb/db2.so
    #0 0x00e18014 in check_pw_reuse (context=0x99a2fc0, hist_keyblock=0xe29e08,
    n_new_key_data=4, new_key_data=0x99a5890, n_pw_hist_data=2,
    pw_hist_data=0x99a26e0) at svr_principal.c:955
    955 if ((newkey.length == histkey.length) &&
    (gdb) list
    950 &pw_hist_data[y].key_ data[z],
    951 &histkey, NULL);
    952 if (ret)
    953 return(ret);
    954
    955 if ((newkey.length == histkey.length) &&
    956 (newkey.enctype == histkey.enctype) &&
    957 (memcmp(newkey.contents, histkey.contents,
    958 histkey.length) == 0)) {
    959 krb5_free_keyblock_contents(context, &histkey);
    (gdb) print newkey.length
    $1 = 32
    (gdb) print histkey.length
    $2 = 32
    (gdb) print newkey.enctype
    $3 = 18
    (gdb) print histkey.enctype
    $4 = 18
    (gdb) print newkey.contents
    $5 = (krb5_octet *) 0x99a57d0 " )\023 ^ Nid 3p X\036 \212- \004"
    (gdb) print histkey.contents
    $6 = (krb5_octet *) 0x0
    (gdb)


    FYI, gdb output from kadmin.local in Kerberos 5 Version 1.4.1:

    [root@sixoften krb5kdc]# kadmin.local
    Authenticating as principal mbrookov/admin@DEVMINES.EDU with password.
    kadmin.local: cpw testub
    Enter password for principal "testub":
    Re-enter password for principal "testub":
    Segmentation fault (core dumped)
    [root@sixoften krb5kdc]#
    [root@sixoften krb5kdc]# gdb /usr/local/sbin/kadmin.local core.2419
    GNU gdb Red Hat Linux (6.3.0.0-1.63rh)
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

    Core was generated by `kadmin.local'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /usr/local/lib/libkadm5srv.so.5...done.
    Loaded symbols for /usr/local/lib/libkadm5srv.so.5
    Reading symbols from /usr/local/lib/libkdb5.so.4...done.
    Loaded symbols for /usr/local/lib/libkdb5.so.4
    Reading symbols from /usr/local/lib/libgssrpc.so.4...done.
    Loaded symbols for /usr/local/lib/libgssrpc.so.4
    Reading symbols from /usr/local/lib/libgssapi_krb5.so.2...done.
    Loaded symbols for /usr/local/lib/libgssapi_krb5.so.2
    Reading symbols from /usr/local/lib/libkrb5.so.3...done.
    Loaded symbols for /usr/local/lib/libkrb5.so.3
    Reading symbols from /usr/local/lib/libk5crypto.so.3...done.
    Loaded symbols for /usr/local/lib/libk5crypto.so.3
    Reading symbols from /usr/local/lib/libcom_err.so.3...done.
    Loaded symbols for /usr/local/lib/libcom_err.so.3
    Reading symbols from /usr/local/lib/libkrb5support.so.0...done.
    Loaded symbols for /usr/local/lib/libkrb5support.so.0
    Reading symbols from /lib/libresolv.so.2...done.
    Loaded symbols for /lib/libresolv.so.2
    Reading symbols from /lib/tls/libc.so.6...done.
    Loaded symbols for /lib/tls/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...done.
    Loaded symbols for /lib/ld-linux.so.2
    #0 0x00af0f84 in check_pw_reuse (context=0x89aaa38, hist_keyblock=0xb03bc8, n_new_key_data=4, new_key_data=0x89abad0,
    n_pw_hist_data=2, pw_hist_data=0x89aa708) at svr_principal.c:882
    882 if ((newkey.length == histkey.length) &&
    (gdb) where
    #0 0x00af0f84 in check_pw_reuse (context=0x89aaa38, hist_keyblock=0xb03bc8, n_new_key_data=4, new_key_data=0x89abad0,
    n_pw_hist_data=2, pw_hist_data=0x89aa708) at svr_principal.c:882
    #1 0x00af159c in kadm5_chpass_principal_3 (server_handle=0x89aa9c0, principal=0x89aa110, keepold=0, n_ks_tuple=0,
    ks_tuple=0x0, password=0x80540e0 "testing1234") at svr_principal.c:1307
    #2 0x00af199b in kadm5_chpass_principal (server_handle=0x89aa9c0, principal=0x89aa110, password=0x80540e0 "testing1234")
    at svr_principal.c:1203
    #3 0x0804b43e in kadmin_cpw (argc=1, argv=0x89abeb0) at kadmin.c:711
    #4 0x0804f3fc in really_execute_command (sci_idx=1, argc=2, argv=0xbff8728c) at execute_cmd.c:89
    #5 0x0804f50b in ss_execute_line (sci_idx=1, line_ptr=0xbff896f0 "cpw") at execute_cmd.c:215
    #6 0x0804f74e in ss_listen (sci_idx=1) at listen.c:125
    #7 0x0804cf1d in main (argc=1, argv=0xbff8b7d4) at ss_wrapper.c:62
    (gdb)


    If I delete the principal and create a new principal with the same name
    the new principal works. I can use cpw from kadmin on the new principal
    to change the password and every thing is fine. After some amount of
    time, the principal will stop working.

    The above patch just stops the core dumps and allows the password to be
    changed without having to delete and create the principal.

    I have only experienced this problem on my development system. The
    production system generates the same warning messages from kdb5_util
    dump, but we have not had any trouble with kadmind dumping core.

    It looks like both 1.4.1 and 1.5.2 have the same problem. I have not
    figured out what set of changes to the data base triggers this problem.

    Please let me know if you have any ideas.

    thank you

    Matt
    mbrookov@mines.edu

    On Sat, 2007-04-07 at 19:08 -0600, Matthew B. Brookover wrote:

    > I did a kdb5_util dump and a kdb5_util dump -ov from Kerberos 5 version
    > 1.4.1, the -ov option generates some warnings:
    >
    > [root@s1 krb5kdc]# kdb5_util dump s1-old-kdb-dump
    > [root@s1 krb5kdc]# kdb5_util dump -ov s1-old-kdb-dump.ov
    > Warning! No DES-CBC-CRC key for principal testua@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > Warning! No DES-CBC-CRC key for principal testua@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > Warning! No DES-CBC-CRC key for principal testuc@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > Warning! No DES-CBC-CRC key for principal testuc@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > Warning! No DES-CBC-CRC key for principal testud@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > Warning! No DES-CBC-CRC key for principal testuf@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > Warning! No DES-CBC-CRC key for principal testuf@DEVMINES.EDU, cannot
    > generate OV-compatible record; skipping
    > [root@s1 krb5kdc]#
    >
    > When I try to import the file into Kerberos 5 version 1.5.2 I get more
    > messages:
    >
    > [root@s1 krb5kdc]# kdb5_util load s1-old-kdb-dump
    > [root@s1 krb5kdc]# kdb5_util load -update s1-old-kdb-dump.ov
    > (null): Unknown code imp 4 testua@DEVMINES.EDU
    > (null): Unknown code imp 4 testua@DEVMINES.EDU
    > (null): Unknown code imp 4 testuc@DEVMINES.EDU
    > (null): Unknown code imp 4 testuc@DEVMINES.EDU
    > (null): Unknown code imp 4 testud@DEVMINES.EDU
    > (null): Unknown code imp 4 testuf@DEVMINES.EDU
    > (null): Unknown code imp 4 testuf@DEVMINES.EDU
    > [root@sixoften krb5kdc]#
    >
    > What do the warnings from the dump mean?
    >
    > Also, what does the corresponding error from the load mean?
    >
    > There are other principals in the kdc that do not generate any warnings
    > or errors. In kadmin the the principals look fine after the load.
    > Unfortunately, I do not have passwords for these principals.
    >
    > Thank You.
    >
    > Matt
    > mbrookov@mines.edu
    >
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread