-randkey is not accepted at all
[root@mega ~]# kadmin -p admin/admin
Authenticating as principal admin/admin with password.
Password for admin/admin@FOO:
kadmin: getprinc foo
get_principal: Principal does not exist while retrieving "foo@FOO".
kadmin: addprinc -randkey foo
WARNING: no policy specified for foo@FOO; defaulting to no policy
add_principal: Invalid argument while creating "foo@FOO".
kadmin: quit
[root@mega ~]# rpm -qa | grep krb5
krb5-devel-1.6.1-31.el5_3.3
pam_krb5-2.2.14-10
krb5-libs-1.6.1-31.el5_3.3
krb5-workstation-1.6.1-31.el5_3.3
[root@mega ~]# uname -a
Linux mega.foo.org 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009
i686 i686 i386 GNU/Linux
[root@mega ~]#
Server is MIT 1.7
Previous info:
On 12/23/2009 2:02 PM, Jeff Blaine wrote:
> I'm stumped:
>
> kadmin: addprinc -randkey host/192.168.1.6
> WARNING: no policy specified for host/192.168.1.6@FOO; defaulting to no
> policy
> add_principal: Invalid argument while creating "host/192.168.1.6@FOO".
> kadmin:
>
> on KDC, kadmin.log says:
>
> Dec 23 13:58:57 noodle kadmind[661](Notice): Request:
> kadm5_create_principal, host/192.168.1.6@FOO, Invalid argument,
> client=admin/admin@FOO, service=kadmin/admin@FOO, addr=192.168.1.6
> Still very very stumped. Any ideas? Anyone?
>
> -randkey is not accepted at all
>
> [root@mega ~]# kadmin -p admin/admin
> Authenticating as principal admin/admin with password.
> Password for admin/admin@FOO:
> kadmin: getprinc foo
> get_principal: Principal does not exist while retrieving "foo@FOO".
> kadmin: addprinc -randkey foo
> WARNING: no policy specified for foo@FOO; defaulting to no policy
> add_principal: Invalid argument while creating "foo@FOO".
> kadmin: quit
Do you get the same behavior running kadmin.local on the KDC?
> No, that works fine.
When running kadmin remotely, does "addprinc" without "-randkey"
succeed?
Yup.
> On 12/28/2009 9:41 PM, Tom Yu wrote:
>> Jeff Blaine<jbl...@kickflop.net> writes:
>>
>>> No, that works fine.
>>
>> When running kadmin remotely, does "addprinc" without "-randkey"
>> succeed?
>
> Yup.
This is probably a known bug, #6074. It was fixed in krb5-1.7, but
not back-ported to 1.6.x. Basically, krb5-1.7 causes the RC4
string-to-key to perform a proper UTF-8 conversion, and the "dummy"
password that kadmin uses for performing the "addprinc -randkey"
operation contains octet sequences that are not valid UTF-8. It's
kind of an impedance mismatch between krb5-1.7 and earlier kadmin
clients. Do you have RC4 ("arcfour-hmac-md5", etc.) configured in
your "supported_enctypes" on that KDC?
http://krbdev.mit.edu/rt/Ticket/Display.html?id=6074&user=guest&pass=guest
I don't understand why I would need to specify that (?)
For example, this principal was created on the KDC box
via the same MIT 1.7 install tree that the KDC runs with:
Principal: krbtgt/FOO@FOO
...
Number of keys: 4
Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, ArcFour with HMAC/md5, no salt <-----------
MKey: vno 1
...
Tom was asking that to verify that his understanding of your problem was
correct; he wasn't suggesting a workaround.
The problem is that addprinc -randkey works in an odd way: it creates
the principal with a dummy password (and a flag to disallow issuing of
tickets) and then asks the kadmin server to randomize the password.
In krb5 1.6, the dummy password is a 255-byte string containing all
possible byte values. This is what causes the problem with a krb5 1.7
server if you're supporting RC4 keys, because that dummy password is not
valid UTF-8. krb5 1.7 clients use a different dummy password which
doesn't have this problem.
Jeffrey Altman
That's a good idea, and I'll try to implement it for 1.7 and 1.8 in the
near future.