We have a (large?) principal database that takes forty seconds to dump
with kdb5_util. While this is going on krb5kdc stops responding to
authentication and ticket requests. It happily continues once the dump
is complete.
We are running MIT krb5 1.12.1 on Scientific Linux 6.
Incremental
Does Kerberos5 have the ability to store user-defined attributes
somehere and distribute them to the Kerberos5 clients?
Wendy
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
I have experienced this issue before in a similar manner (we do a regular
dump of a very large Kerberos database, and the Kerberos process would stop
serving requests while this dump was happening).
We solved this problem by completely disabling account lockout and access
tracking, i.e.:
On Fri, 2014-04-25 at 09:52 -0400, Carlos Más wrote:
I have experienced this issue before in a similar manner (we do a
regular dump of a very large Kerberos database, and the Kerberos
process would stop serving requests while this dump was happening).
We solved this problem by completely
On Fri, 2014-04-25 at 15:05 +0100, Kenneth MacDonald wrote:
Thinking aloud ... I wonder how difficult it would be to have krb5kdc
optionally stop recording failures while the database is locked.
FWIW, Heimdal uses a transaction log, like a real database manager.
Changes go into the log and can
On 04/25/2014 10:05 AM, Kenneth MacDonald wrote:
Thinking aloud ... I wonder how difficult it would be to have krb5kdc
optionally stop recording failures while the database is locked.
The database is frequently locked for short periods of time, so I think
this would make failure recording
Sorry to trudge up a thread a couple of months old - but I believe that the
behavior I'm seeing is directly related to this and instead of coming in
grasping at straws, I decided it would be best to use this as context.
I have a heterogeneous environment with a windows KDC which both my user
and
Your understanding is correct but credential delegation requirements are
API dependent instead of platform.
For Unix :
Putty uses MIT Kerberos - GSS API. When you enable delegation in putty it
requests GSS_C_DELEG_FLAG instead of GSS_C_DELEG_POLICY_FLAG which doesn't
check ok_as_delegate_flag,
On 04/25/2014 06:04 PM, Ben H wrote:
04/25/14 16:34:02 04/26/14 02:31:06 host/centos64-01.mydomain.local@
Flags: FA
04/25/14 16:34:02 04/26/14 02:31:06
host/centos64-01.mydomain.local@MYDOMAIN.LOCAL
Flags: FA
These are the same ticket cached under two different
Great - thanks Greg - beginning to be much clearer.
So the TGT from B is actually a full request for the forwardable ticket
(not just a notification) and it gets sent right to the remote machine and
not cached locally.
I can confirm this with the issued time stamp not changing on the host, but
On 04/25/2014 07:16 PM, Ben H wrote:
Is there some way to show a mapping that these two tickets are really
identical?
In theory it would be possible to checksum the tickets and tell that
they are the same, but list doesn't know how to do this.
Is the empty realm display really necessary once
Ben H bhen...@gmail.com writes:
Based on your prior explanation I can't help but infer this means that
although the new forwardable TGT session key may be different than my
original TGT, it is still shared between all hosts that I delegate to,
leading to a possible attack against all systems
12 matches
Mail list logo
