beta7: kadmin: Communication failure with server while initializing kadmin interface
Trever Furnish
Ok, I'm still stuck.
My problem, very briefly, is that when I start kadmin in section 4.1.2.1
of the installation guide, it asks me for my password, the responds with the
following error when I enter the password and hit return:
kadmin: Communication failure with server while initializing kadmin interface
I *know* the password's correct; I've tested it, changed it, etc. I've also
been told by several people that I "need to use kadmin.local, since the
servers haven't been started yet," but the servers *have* been started --
they're started in the section before that, 4.1.1.6. So far, I've written
off those suggestions as being from someone who was confused about what
section I'm in, but if I really do need to use kadmin.local in this section,
regardless of the fact that the servers are running, tell me again. :)
I can't find a description of what the various messages in the log file
mean (Is that file described in one of the man pages I haven't gotten to yet?),
but just guessing, it looks as though a ticket is issued. Here's the
message that gets entered into the log file:
Oct 14 18:01:08 AS_REQ 157.91.128.23(88): ISSUE: authtime 845334068, admin/admin
@IND.NET for kadmin/ad...@IND.NET
Does that mean a ticket is getting issued? Does someone know what might
cause the error?
Any help is *greatly* appreciated.
Sincerely,
Trever
--
Trever Furnish, Talk: tfur...@jefferson.ind.net _ _
tre...@ind.net, WWW: http://dialin.ind.net/~tfurnish `v`
School:317.594.8813 Work:317.263.8999 Home:812.873.6867 FAX:317.263.8831 \_/
INDnet NOC There is no knowledge that is not power. U
Barry Jaspan
I am tracking a similar (maybe the same) problem where an unprived user
can run kadmin fine, but running it under root gives the message:
> kadmin: GSS-API (or Kerberos) error while initializing kadmin interface
> Oct 14 19:33:31 corp-rtr syslog: Miscellaneous RPC error: 204.152.96.34, internal error sealing sequence number
Neither the KDC for KADM5 know or care whether you are running as root
or as some other user. The error messages you are describing have
previously been determined to be the result of Kerberos tickets which
expire *during* the init authentication exchange between kadmin and
kadmind. Therefore, since it works for user/admin but not root/admin,
I suspect that if you check root/admin's maximum ticket lifetime, it
will be zero, whereas user/admin's will not be.
Barry
Brian Topping
Barry Jaspan wrote:
> > kadmin: GSS-API (or Kerberos) error while initializing kadmin interface
>
> > Oct 14 19:33:31 corp-rtr syslog: Miscellaneous RPC error: 204.152.96.34, internal error sealing sequence number
>
> previously been determined to be the result of Kerberos tickets which
> expire *during* the init authentication exchange between kadmin and
> kadmind. Therefore, since it works for user/admin but not root/admin,
> I suspect that if you check root/admin's maximum ticket lifetime, it
> will be zero, whereas user/admin's will not be.
Ta da! Thanks!
So then this leads to the question of default ticket life for newly
created principals. Is this a new feature of B7 that principals are
always created with 0 ticket life?
Thanks!!
-B
Barry Jaspan
So then this leads to the question of default ticket life for newly
created principals. Is this a new feature of B7 that principals are
always created with 0 ticket life?
It's not a feature, it's a bug, and it has been fixed in the
development sources. For now, put "max_life = 10h" or whatever time
you want in the realm block of your kdc.conf, and restart your admin
server.
Barry
Barry Jaspan
Is this a new feature of B7 that principals are always created with
0 ticket life?
It's a bug that has been fixed in the development sources. You need
to add a max_life field to your kdc.conf, like this:
[realms]
DEMO.ORG = {
<other stuff>
max_life = 10h 0m 0s
<other stuff>
}
Travis Jones
Barry Jaspan (bja...@MIT.EDU) wrote:
: section. In fact, why don't you just send your entire krb5.conf (and
: kdc.conf).
: Once you get kadmind's logging messages, the problem (if there is one)
: should be obvious.
Check to make sure in your kdc.conf that
[realms]
...
kadmin_port = ???
...
matches the port specified in your krb5.conf file
admin_server = kerberos.host.domain:???
--
Travis Jones
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!travis
Internet: tra...@prism.gatech.edu
Trever Furnish
Ok, resetting the port in kdc.conf to 749 got me around one error, only to
bring me to another. This time, after it kadmin takes my password (same
section, 4.1.2.1 of the install guide), it reports:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface
Starting with clean log files, I get this in the kadmind logfile:
Oct 16 13:14:32 starting
Oct 16 13:15:18 Authentication attempt failed: 157.91.128.23, GSS-API error
strings are:
Oct 16 13:15:18 Miscellaneous failure
Oct 16 13:15:18 Key table entry not found
Oct 16 13:15:18 GSS-API error strings complete.
and this in the kdc logfile:
Oct 16 13:14:32 commencing operation
Oct 16 13:15:14 AS_REQ 157.91.128.23(88): ISSUE: authtime 845489714,
kadmin/admi n...@IND.NET for kadmin/ad...@IND.NET
Anyone know what would cause *this* error? My krb5.conf and kdc.conf files
follow this. As far as I know, I've followed all the instructions to that
point. The only thing I've done that wasn't in the instructions was to go
ahead and try section 4.1.2.1 using kadmin.local instead of kadmin. In other
words, I issued the addprinc -randkey host/kerberos.ind.net command, and also
addprinc'ed host/noc.ind.net. :-(
Suggestions?
---
trever,
tre...@ind.net
krb5.conf:
[libdefaults]
default_realm = IND.NET
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
krb4_config = /usr/local/krb5-beta7/krb4/lib/krb.conf
krb4_realms = /usr/local/krb5-beta7/krb4/lib/krb.realms
[realms]
IND.NET = {
kdc = KERBEROS.IND.NET
kdc = KERBEROS2.IND.NET
admin_server = KERBEROS.IND.NET
default_domain = IND.NET
}
[domain_realm]
.ind.net = IND.NET
ind.net = IND.NET
[kdc]
profile = /usr/local/lib/krb5kdc/kdc.conf
[logging]
kdc = FILE:/usr/local/krb5-beta7/logs/kdc.log
admin_server = FILE:/usr/local/krb5-beta7/logs/adminsrvr.log
default = FILE:/usr/local/krb5-beta7/logs/default.log
kdc.conf:
[kdcdefaults]
kdc_ports = 750,88
[realms]
IND.NET = {
profile = /etc/krb5.conf
database_name = /usr/local/lib/krb5kdc/principal
admin_database_name = /usr/local/lib/krb5kdc/kadm5_adb
admin_database_lockfile =
/usr/local/lib/krb5kdc/kadm5_adb.lock
admin_keytab = FILE:/usr/local/lib/krb5kdc/kadm5.keytab
acl_file = /usr/local/lib/krb5kdc/kadm5.acl
key_stash_file = /usr/local/lib/krb5kdc/.k5stash
kdc_ports = 750,88
kadmind_port = 749
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des-cbc-crc
supported_enctypes = des-cbc-crc:normal des:normal des:v4
des:no
realm des:onlyrealm des:afs3
}
Regarding my earlier problem, Barry Jaspan wrote:
>
> As you suggested, I looked at the log for the admin server. I didn't send
> it in in the first place, because it only contains the "starting" message.
>
> Ah, but that is critical information... the fact that kadmind logged
> "starting" means that it started correctly and is listening for
> requests. The fact that it isn't logging anything else means that it
> is simply not receiving any data from kadmin.
>
> In fact, the problem is revealed by your krb5.conf and kdc.conf. In
> kdc.conf, you set kadmind_port to 3761. But you do *not* set the same
> port in krb5.conf's admin_server line, and that is what kadmin uses to
> determine what port to talk to. So, you have two choices: (1) delete
> the kadmind_port line from kdc.conf, in which case it will use the
> default (749), or (2) change krb5.conf to read "admin_server =
> kerberos.ind.net:3761".
>
> I suspect that will solve your problem.
>
> Barry
Barry Jaspan
Oct 16 13:15:18 Authentication attempt failed: 157.91.128.23, GSS-API error
strings are:
Oct 16 13:15:18 Miscellaneous failure
Oct 16 13:15:18 Key table entry not found
Oct 16 13:15:18 GSS-API error strings complete.
kadmind is logging "key table entry not found." Immediately before
that, you can see in the KDC log that the kadmin program requested a
ticket for the service "kadmin/ad...@IND.NET". Thus, you can conclude
that there is not an entry for that principal in kadmind's keytab.
From your kdc.conf:
admin_keytab = FILE:/usr/local/lib/krb5kdc/kadm5.keytab
Run klist -k on this file, it should have an entry for two principals,
like this:
% klist -k kadm5.keytab
Keytab name: FILE:kadm5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 kadmin/ad...@IND.NET
3 kadmin/chan...@IND.NET
If it does not (and that's what I suspect), that's the problem. Run
kadmin.local and use the ktadd command. This is in the install
manual, section 4.1.1.5 (this is the section that says to use kadmin
when in fact you should use kadmin.local).
BTW, the extraneous kadmind_port line in your kdc.conf is not entirely
your fault, because it was present in the default kdc.conf (why, I
have no idea); this will be fixed in the next release.
Barry
Trever Furnish
Barry Jaspan wrote:
> Oct 16 13:15:18 Authentication attempt failed: 157.91.128.23, GSS-API error
> strings are:
> Oct 16 13:15:18 Miscellaneous failure
> Oct 16 13:15:18 Key table entry not found
> Oct 16 13:15:18 GSS-API error strings complete.
>
> kadmind is logging "key table entry not found." Immediately before
> that, you can see in the KDC log that the kadmin program requested a
> ticket for the service "kadmin/ad...@IND.NET". Thus, you can conclude
> that there is not an entry for that principal in kadmind's keytab.
> From your kdc.conf:
>
> admin_keytab = FILE:/usr/local/lib/krb5kdc/kadm5.keytab
>
> Run klist -k on this file, it should have an entry for two principals,
> like this:
>
> % klist -k kadm5.keytab
> Keytab name: FILE:kadm5.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
> 3 kadmin/ad...@IND.NET
> 3 kadmin/chan...@IND.NET
>
> If it does not (and that's what I suspect), that's the problem. Run
> kadmin.local and use the ktadd command. This is in the install
> manual, section 4.1.1.5 (this is the section that says to use kadmin
> when in fact you should use kadmin.local).
>
list them, and it had entries for both of them; in fact it had two entries
for both of them, with KVNOs 3 and 4. I went ahead and used the ktremove
command of kadmin.local to remove the KVNO 4 entries, so that my listing is
now identical to what's listed above, and I restarted the servers, but I
still get the same error when I type in the password and the same log
messages from kadmind and krb5kdc.
Are there any other files that might not match? I'm at a loss to even make
guesses about what may be wrong.
---
trever,
tre...@ind.net
> BTW, the extraneous kadmind_port line in your kdc.conf is not entirely
> your fault, because it was present in the default kdc.conf (why, I
> have no idea); this will be fixed in the next release.
>
> Barry
>
Barry Jaspan
> Run klist -k on this file, it should have an entry for two principals,
> like this:
>
> % klist -k kadm5.keytab
> Keytab name: FILE:kadm5.keytab
> KVNO Principal
> ---- -------------------------------------------------------------------
> 3 kadmin/ad...@IND.NET
> 3 kadmin/chan...@IND.NET
What if it *does* have those entries?
"kvno" stands for "key version number," and it is incremented each
time the key is changed. If the keytab has entries for both
kadmin/admin and kadmin/changepw and kadmind is still reporting "key
table entry not found," then it means that the *version* of the key
that the kadmin client sent to kadmind is not in the keytab. Since
kadmin just got those tickets from the KDC, that means the version of
the key in the KDC must not match the version of the key in the
keytab; this simply means the service principal's key has been changed
(with kadmin.local, since kadmind isn't running yet) since you
extracted the keytab entry.
You can verify this situation by running "getprinc kadmin/admin" in
kadmin.local. Look at the key version number field; I bet it won't be
either 3 or 4.
I went ahead and used the ktremove command of kadmin.local to
remove the KVNO 4 entries
Well, given the error from kadmind, it must be the case that neither
kvno 3 nor 4 is right, in which case it really doesn't matter which
ones you removed. But in general, there is no good reason to remove
*new* key versions and keep the old ones, because if a new key exists
in the KDC it is guaranteed that the old kvno will be out of date.
So, to fix this problem, use ktadd again to re-extract kadmin/admin
and kadmin/changepw into kadm5.keytab. The ktadd command changes the
principal's key *and* adds it to the keytab in a single operation, so
you are guaranteed that the keytab ends up with the right key version
(btw, if you think about it, you'll realize that it also means that a
keytab can never have an entry with kvno 1; in fact, given how
create_principal -randkey works, you'll never have a keytab entry with
kvno less than 3; this doesn't matter). Restart kadmind (shouldn't be
necessary, actually), and try running kadmin again.
At this point, Trever, I suspect your problems are caused by the fact
that you have tried so many random things to get your system working
that you have accidentally run some commands you did not understand.
Whether or not this message gets your system working, I suggest you
delete everything and start over to make sure you can get it working
from scratch.
Barry