I thought of another possible workaround that doesn't involve code
changes to 1.14, which is to do (in kadmin):
setstr krbtgt/REALM session_enctypes "aes256-cts aes128-cts"
I have opened http://krbdev.mit.edu/rt/Ticket/Display.html?id=8167 for
this issue, and we may introduce a KDC workaround i
On 11/18/2016 02:08 PM, Greg Hudson wrote:
> Unfortunately, neither backporting the 1.14 tgt rekeying fixes
> nor forward-porting the 1.13 pa-etype-info2 behavior is likely to be
> easy, so I can't offer a solution better than the ones you've already
> determined.
Actually, you could try reintrodu
On 11/18/2016 12:15 PM, Dameon Wagner wrote:
> Before I explain why I think we're seeing issues, it might be simplest
> if I first ask: Is there a configuration option that we can set to
> use the "old behaviour", and have multiple PA-ETYPE-INFO2-ENTRY items
> returned?
No; we didn't expect the c
You might be able to do some sort of powershell script? I don't think the
KFW has a startup context to it. The thin is you would need to pass
credentials in somehow which starts to weaken the integrity of the security
model once you start caching passwords/keytabs. We should know, Hadoop is
the
I've been informed that mail to my other address will be blocked. Please
respond to this mail, and I should receive it. I apologize for the spam
and inconvenience and thank you for your assistance.
-- Forwarded message --
From: June Newman
Date: Fri, Nov 18, 2016 at 10:16 AM
Afternoon all,
During a recent upgrade of our KDCs (to 1.14 we've backported to
debian jessie), we stumbled across a behavioural change related to
rfc6113, and have ended up downgrading to the 1.12 that's in jessie's
stable repository.
The change we're seeing is that in krb5-1.12 a
KDC_ERR_PREAUT
One more thing: if MIT Kerberos is installed, is there a way to populate the
KRB5CCNAME cache file automatically when I log on to Windows without having to
use a keytab or having to run a kinit under the covers?
From: Todd Grayson [mailto:tgray...@cloudera.com]
Sent: Friday, November 18, 2016 11
On 11/18/2016 10:16 AM, June Newman wrote:
> Our KDCs are running CentOS 6.8 and we have the latest kerb
> implementation for Cent 6.
What version of krb5 is that?
> We've tried to work around the corrupt principals by running 'kdb5_util
> dump -recurse' and 'kdb5_util dump -rev' but it has made
Thanks Todd. I was thinking the same thing, but I just wasn’t sure.
From: Todd Grayson [mailto:tgray...@cloudera.com]
Sent: Friday, November 18, 2016 11:34 AM
To: Mauro Cazzari
Cc: Kerberos@mit.edu
Subject: Re: Can I automatically cache AD tickets into a file on windows?
From what I understand,
>From what I understand, the windows SSPI implementation does not provide a
facility to hold the credentials in a file. You would use the MIT KFW to
be able to do that.
On Friday, November 18, 2016, Mauro Cazzari wrote:
> Kerberos experts,
> Is there a way to automatically cache AD-generated ti
Kerberos experts,
Is there a way to automatically cache AD-generated tickets to the file provided
through the KRB5CCNAME environment variable on Windows without having to run a
kinit? My understanding is that Windows caches tickets in memory (whereas Unix
does the same on file). Do I need to ins
We have a long running enterprise kerberos system that appears to have
corruption. Our KDCs are running CentOS 6.8 and we have the latest kerb
implementation for Cent 6.
Yesterday morning, we starting seeing problems with some users not being
able to authenticate, and as the morning progressed th
12 matches
Mail list logo
