On Mon, 2013-05-27 at 18:04 -0400, Benjamin Kaduk wrote:
Thanks for these. It looks like the salt that the KDC is sending back
with the AS_REP is CERN.CHchristoph.anton.mitterer, but the salt that
ktutil would use is just CERN.CHmitterer. Since these are not the same,
the key generated
Well, is there any reason you're not using the full name for the
principal in the keytab?
in AD, i'd expect that to work too.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Tue, 2013-05-28 at 09:02 -0400, Sam Hartman wrote:
Well, is there any reason you're not using the full name for the
principal in the keytab?
in AD, i'd expect that to work too.
Uhm... the full name isn't the actual username,... and it seems neither
it is known as a kerberos principal:
$
i think you need to reclose the bug not simply mark it as fixed again.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Tue, 28 May 2013, Christoph Anton Mitterer wrote:
ktutil is not smart enough to allow the user to specify a non-default
salt
Given that this seems to be quite widespread then (I mean AD is evil,
but used in many places)... do you seen any chances upstream, to extend
ktutil accordingly?
I
fixed 698534 1.11.2+dfsg-1
thanks
On Sun, 26 May 2013, Christoph Anton Mitterer wrote:
See the attachments (kinit for what happened with plain kinit, kutil for
what happened with the keytab).
Thanks for these. It looks like the salt that the KDC is sending back
with the AS_REP is
reopen 698534
stop
Hi.
Are you really sure that this has been fixed?
$ apt-cache policy krb5-user
krb5-user:
Installed: 1.11.2+dfsg-1
$ kinit mitte...@cern.ch
Password for mitte...@cern.ch:
$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: mitte...@cern.ch
Valid starting
On Sun, 26 May 2013, Christoph Anton Mitterer wrote:
$ kinit mitte...@cern.ch
Password for mitte...@cern.ch:
$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: mitte...@cern.ch
Valid starting Expires Service principal
2013-05-26 12:04:33 2013-05-27 12:04:19
Hey Benjamin.
On Sun, 2013-05-26 at 15:17 -0400, Benjamin Kaduk wrote:
Can you run the two kinit commands with KRB5_TRACE set in the environment
to the path to a log file and capture a trace log? (Use a different
KRB5_TRACE setting for each run to get separate logfiles, please.) That
So, if you type kinit foo@REALM
then run kvno foo@REALM
My suspicion is that to what extent kvno matters for tgts has changed
recently.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Sam.
On Tue, 2013-01-22 at 15:19 -0500, Sam Hartman wrote:
So, if you type kinit foo@REALM
then run kvno foo@REALM
That doesn't work:
$ kinit mitte...@cern.ch
Password for mitte...@cern.ch:
$ kvno mitte...@cern.ch
kvno: Server not found in Kerberos database while getting credentials
for
My guess is that you have the wrong kvno.
Can you try runnig the kvno command on the principal in question
immediately after a successful kinit?
It's possible that your KDC won't let you find out the kvno that way in
which case things are more difficult to diagnose.
--Sam
--
To UNSUBSCRIBE,
Hi Sam.
On Sun, 2013-01-20 at 17:41 -0500, Sam Hartman wrote:
My guess is that you have the wrong kvno.
That would be strange, cause I use the very same kvno on Scientific
Linux (where it works).
Also some of the CERN guys told me, it would be ignored for TGTs, but
I'm by no means an expert in
Package: krb5-user
Version: 1.10.1+dfsg-3
Severity: important
Hi
(@Russ: This is partially also, what I wrote you already in private).
It seems that Debians Kerberos have some problems with using keytabs,
at least with some remote KDCs.
What I do is always about this.
1) Creating a keytab
14 matches
Mail list logo
