[krbdev.mit.edu #8038] Kadmind/kadmin.local issues after migration from version 1.12.2 to 1.13
Andrei Maslennikov via RT
rt-comment at krbdev.mit.edu
Thu Nov 20 04:04:04 EST 2014
Hello, it seems we are getting closer to the origin of the loop!
This is what happens with the looping kadmin.local:
------------------------------------------------------------
[root at sys cli]# pwd
/sys.1/Trash/K5/krb5-1.13/src/kadmin/cli
[root at 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 at sys cli]# ./kadmin.local
Authenticating as principal root/admin at MASL.EU with password.
<entered the loop>
-------------------------------------------------------------
In another window:
[root at sys cli]# pwd
/sys.1/Trash/K5/krb5-1.13/src/kadmin/cli
[root at 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 at 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 at sys krb5kdc]# /usr/k5.vanilla/sbin/kadmin.local
Authenticating as principal root/admin at MASL.EU with password.
kadmin.local: getprinc testus
Principal: testus at 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 at 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 at krbdev.mit.edu> wrote:
> [andrei.maslennikov at 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.
>
More information about the krb5-bugs
mailing list