Hello, it seems we are getting closer to the origin of the loop!


This is what happens with the looping kadmin.local:

------------------------------------------------------------
[root@sys cli]# pwd
/sys.1/Trash/K5/krb5-1.13/src/kadmin/cli

[root@sys cli]# ls
deps       getdate.y     kadmin.c      kadmin_ct.o   kadmin.o        keytab_local.o  Makefile.in   strftime.c
getdate.c  k5srvutil.sh  kadmin_ct.c   kadmin.h      keytab.c        keytab.o        ss_wrapper.c
getdate.o  kadmin        kadmin_ct.ct  kadmin.local  keytab_local.c  Makefile        ss_wrapper.o

root@sys cli]# ./kadmin.local
Authenticating as principal root/admin@MASL.EU with password.
<entered the loop>
-------------------------------------------------------------

In another window:

[root@sys cli]# pwd
/sys.1/Trash/K5/krb5-1.13/src/kadmin/cli

[root@sys cli]# ps -ef | grep kadmin.local | grep -v grep
root     29736     1 36 09:24 pts/2    00:00:07 /sys.1/Trash/K5/krb5-1.13/src/kadmin/cli/kadmin.local
root     29738 29775 99 09:24 pts/3    00:00:03 ./kadmin.local

[root@sys cli]# gdb kadmin.local
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /sys.1/Trash/K5/krb5-1.13/src/kadmin/cli/kadmin.local...done.
(gdb) attach 29736
Attaching to program: /sys.1/Trash/K5/krb5-1.13/src/kadmin/cli/kadmin.local, process 29736
Reading symbols from /usr/lib64/libedit.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libedit.so.0
Reading symbols from /lib64/libncurses.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib64/libncurses.so.5
Reading symbols from /usr/k5.vanilla/lib/libkadm5srv_mit.so.9...done.
Loaded symbols for /usr/k5.vanilla/lib/libkadm5srv_mit.so.9
Reading symbols from /usr/k5.vanilla/lib/libkdb5.so.8...done.
Loaded symbols for /usr/k5.vanilla/lib/libkdb5.so.8
Reading symbols from /usr/k5.vanilla/lib/libgssrpc.so.4...done.
Loaded symbols for /usr/k5.vanilla/lib/libgssrpc.so.4
Reading symbols from /usr/k5.vanilla/lib/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/k5.vanilla/lib/libgssapi_krb5.so.2
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/k5.vanilla/lib/libkrb5.so.3...done.
Loaded symbols for /usr/k5.vanilla/lib/libkrb5.so.3
Reading symbols from /usr/k5.vanilla/lib/libk5crypto.so.3...done.
Loaded symbols for /usr/k5.vanilla/lib/libk5crypto.so.3
Reading symbols from /usr/k5.vanilla/lib/libcom_err.so.3...done.
Loaded symbols for /usr/k5.vanilla/lib/libcom_err.so.3
Reading symbols from /usr/k5.vanilla/lib/libkrb5support.so.0...done.
Loaded symbols for /usr/k5.vanilla/lib/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib64/libtinfo.so.5
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000003063b2cb98 in __strcasecmp_l_sse42 () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 libedit-2.11-4.20080712cvs.1.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
(gdb)


With a little more luck, in another run:
...
Loaded symbols for /lib64/libtinfo.so.5
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
krb5_string_to_enctype (string=0x12aa7e2 "arcfour-hmac", enctypep=0x7fff089274f8) at enctype_util.c:77
77      enctype_util.c: No such file or directory.
        in enctype_util.c
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 libedit-2.11-4.20080712cvs.1.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
(gdb) quit

I.e. it looks like kadmin.local goes mad while comparing strings or looking for encryption type "arcfour-hmac".

At this point, I looked againd at the kdc.conf.


I had:

[realms]
 MASL.EU = {
 master_key_type = aes256-cts-hmac-sha1-96
 database_name = /var/k5/krb5kdc/principal
 supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal rc4-hmac:normal rc4-hmac-exp:normal des-cbc-crc:v4 des-cbc-crc:afs3 arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm arcfour-hmac-md5:normal des3-hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal
 max_life = 30d
 default_principal_flags = +preauth
 }

Then I removed these enctypes:

"arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm arcfour-hmac-md5:normal"

At this point - no more loops!!! kadmin.local worked ok.

Thus the issue is turning around "arcfour-hmac". My current list of encryption types includes this
family, and I have to keep them there as the principals already possess the corresponding keys:


[root@sys krb5kdc]# /usr/k5.vanilla/sbin/kadmin.local
Authenticating as principal root/admin@MASL.EU with password.
kadmin.local:  getprinc testus
Principal: testus@MASL.EU
Expiration date: [never]
Last password change: Mon Dec 30 22:53:38 CET 2013
Password expiration date: [none]
Maximum ticket life: 30 days 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Mon Dec 30 22:53:38 CET 2013 (root/admin@MASL.EU)
Last successful authentication: Wed Nov 19 08:55:21 CET 2014
Last failed authentication: Thu Oct 02 12:41:56 CEST 2014
Failed password attempts: 0
Number of keys: 10
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
Key: vno 1, arcfour-hmac
Key: vno 1, des-cbc-crc:v4
Key: vno 1, des-cbc-crc:afs3
Key: vno 1, arcfour-hmac:norealm
Key: vno 1, arcfour-hmac:onlyrealm
Key: vno 1, des3-cbc-sha1
Key: vno 1, des-hmac-sha1
Key: vno 1, des-cbc-md5
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

To conclude:

- the working kadmin version 1.12.2 has no problems with the quoted kdc.conf

- the new kadmin version 1.13 goes mad about certain encryption types and
you should be able to easily reproduce this behaviour in your own test environment
by adding these enctypes to your kdc.conf:

"arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm arcfour-hmac-md5:normal"

(If I recall it correctly, "arcfour-hmac" is used on Windows clients, and we have some
Win machines that get the authentication from K5MIT and not from AD).

What could be done about it?

Cheers - Andrei.

PS I have mentioned that the Builds directory of my yesterday's tar file was
in fact containing two times 1.12.2 builds and not 1.12.2 and 1.13. I have
hence replaced the tar.file with the one correcting the correct Builds subdir,
sorry for this mistake. You may again grab it at:

       http://afsita.masl.eu/k5/k5.debug.tgz







 




































On Thu, Nov 20, 2014 at 3:12 AM, Benjamin Kaduk via RT <rt-comment@krbdev.mit.edu> wrote:
[andrei.maslennikov@gmail.com - Wed Nov 19 04:09:49 2014]:

> Hello Benjamin, and many hanks for looking into this!
>
> Please grab this tar.gz file containing the strace and ltrace logs for
> kadmin.local,
> both for working 1.12.2 and hanging 1.13, both binary builds for 1.12.2 and
> 1.13,
> kdc.conf and krb5.conf:

Many thanks for the very comprehensive listing.

Do you by any chance have something like a password quality module or some other out-of-tree
plugin module installed?

I think the next step may be to attach gdb to the spinning/hung kadmin.local and get a
backtrace.