Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

principal: Invalid argument while creating "foo@FOO".

906 views
Skip to first unread message

Jeff Blaine

unread,
Dec 28, 2009, 8:51:26 PM12/28/09
to kerb...@mit.edu
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

[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

Tom Yu

unread,
Dec 28, 2009, 9:03:08 PM12/28/09
to Jeff Blaine, kerb...@mit.edu
Jeff Blaine <jbl...@kickflop.net> writes:

> 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?

Jeff Blaine

unread,
Dec 28, 2009, 9:08:44 PM12/28/09
to Tom Yu, kerb...@mit.edu
No, that works fine.

Tom Yu

unread,
Dec 28, 2009, 9:41:27 PM12/28/09
to Jeff Blaine, kerb...@mit.edu
Jeff Blaine <jbl...@kickflop.net> writes:

> No, that works fine.

When running kadmin remotely, does "addprinc" without "-randkey"
succeed?

Jeff Blaine

unread,
Dec 28, 2009, 9:43:59 PM12/28/09
to Tom Yu, kerb...@mit.edu
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.

Tom Yu

unread,
Dec 28, 2009, 10:17:19 PM12/28/09
to Jeff Blaine, kerb...@mit.edu
Jeff Blaine <jbl...@kickflop.net> writes:

> 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

Jeff Blaine

unread,
Dec 29, 2009, 11:39:03 AM12/29/09
to Tom Yu, kerb...@mit.edu
On 12/28/2009 10:17 PM, Tom Yu wrote:
> Jeff Blaine<jbl...@kickflop.net> writes:
>
>> 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?

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
...

Greg Hudson

unread,
Dec 29, 2009, 12:47:45 PM12/29/09
to Jeff Blaine, Tom Yu, kerb...@mit.edu
On Tue, 2009-12-29 at 11:39 -0500, Jeff Blaine wrote:
> > Do you have RC4 ("arcfour-hmac-md5", etc.) configured in
> > your "supported_enctypes" on that KDC?
>
> I don't understand why I would need to specify that (?)

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

unread,
Dec 29, 2009, 1:02:31 PM12/29/09
to ghu...@mit.edu, Jeff Blaine, Tom Yu, kerb...@mit.edu
May I suggest that in order to provide for backward compatibility that
kadmin recognize the
well-known dummy password and the use of the disallow-tickets flag and
replace the dummy
password with one that will succeed.

Jeffrey Altman


Greg Hudson

unread,
Dec 29, 2009, 2:55:38 PM12/29/09
to jal...@secure-endpoints.com, kerb...@mit.edu
On Tue, 2009-12-29 at 13:02 -0500, Jeffrey Altman wrote:
> May I suggest that in order to provide for backward compatibility that
> kadmin recognize the
> well-known dummy password and the use of the disallow-tickets flag and
> replace the dummy
> password with one that will succeed.

That's a good idea, and I'll try to implement it for 1.7 and 1.8 in the
near future.


0 new messages