[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with kpasswd
Dr A V Le Blanc <LeBlanc@mcc.ac.uk> writes:
> OK, I now have this:
>
> [realms]
> man.ac.uk = {
> kdc = avl.mcc.ac.uk
> admin_server = avl.mcc.ac.uk
> }
>
> And I still have the problem:
>
> kpasswd testname
> testname@man.ac.uk's Password:
> New password:
> Verifying password - New password:
> kpasswd: krb5_change_password: Unknown error 4294967288
So this is a different error:
# define EAI_SERVICE -8 /* SERVICE not supported for `ai_socktype'. */
Which does seem rather bogus to me. getaddrinfo should get called
with ai_socktype = 0, hostname `avl.mcc.ac.uk' and port `749'. But it
seems that the NRL getaddrinfo() in glibc can't cope with that. I
should try to figure out if that's true or bogus. Meanwhile, you
should be able to work-around it by specifying:
admin_server = udp/avl.mcc.ac.uk
> Incidentally, I notice that there are in the database both
> kadmin/changepw and changepw/kerberos principles, installed
> by 'init' under kadmin.
Yes, kadmin/changepw is used by kpasswd and changepw/kerberos for v4
kadmin support.
> As a further problem, I notice that, while 'kadmin -l' works,
> kadmin attaching to kadmind does not; that is, inetd calls
> kadmind successfully, but nothing seems to give me
> 'get privilege', so that get and list fail, and the command
> 'dump', though listed by 'help', doesn't work; it gives the
> error message:
>
> kadmin> dump
> Unrecognized command: dump
load and dump only work with local kadmin (`kadmin -l').
To give out privledges: add stuff similar to this example to
/var/heimdal/kadmind.acl:
leblanc/admin@man.ac.uk all
This is actually mentioned in the documentation under `Remote
administration'. :-)
> OK, I shall try to experiment with this, and if I can get it to
> work, I'll submit suggested text for the documentation.
Great.
> Do I understand that
>
> (1) The krb5.conf file should include, under [realms], in the
> section for my cell, the line
>
> enable_kaserver = hostname?
No, you should have in /var/heimdal/kdc.conf:
[kdc]
enable-kaserver = true
(sorry about the underscore before, it's supposed to be `-').
You can also add it to krb5.conf but then you need to add `-c
/etc/krb5.conf' to kdc, otherwise the default is `kdc.conf' in the
database directory.
> (2) The ka database is kept independently from the kerberos 5 one?
> I mean, because you said above that hprop has distinct ka
> options. Or is there one database served in two modes?
No, it's the same database (the heimdal one). The ka-serer database
is not touched at all by the kdc, just read by hprop. The kdc serves
all three of the kerberos 5, kerberos 4, and kaserver protocols from
the same process and database.
> Actually, I am running 0.2o. I have upgraded my system from
> glibc2.0 to glibc2.1, and had an incidental problem that the
> kdc compiled against the new libraries couldn't read the old
> database.
I believe they changed db version between 2.0 and 2.1, is that true?
> But I simply deleted the old database and ran replay_log.
That should work fine. `replay_log' is however not as old, stable,
and reliable as `kadmin -l dump', so I would suggest using that
instead. It also has the advantage of being able to read and/or edit
the contents fairly easy.
> Clearly it will be wise to keep a dump of the database in case
> of such problems arising in the future.
Right.
/assar