> On Dec 12, 2022, at 3:24 PM, Greg Hudson wrote:
>
> On 12/12/22 14:04, John Devitofranceschi wrote:
>> % cat mykrb5.conf
>> [libdefaults]
>> default_ccache_name = FILE:/my_ccache_location/krbcc_%{uid}
>> include /etc/krb5.conf
>
>> I cannot find a de
Greetings!
I would like to create an application specific krb5.conf where I can override
some system-wide settings while still taking advantage of the rest.
As an example would something like this work if I wanted to define my own
ccache location and name format?
% cat mykrb5.conf
[libdefaults
> On May 9, 2022, at 3:03 PM, Andrej Mikus wrote:
> I am pointing KRB5_CONFIG to a file with correct KDC address/name, but
> kinit always refers to the IP specified in /etc/krb5.conf.
>
> It is my understanding that setting environment variable overrides any
> use of files in /etc, also the tes
> On Sep 18, 2021, at 8:21 AM, John Devitofranceschi wrote:
>
> On Sep 18, 2021, at 12:50 AM, Greg Hudson wrote:
>>
>> On 9/17/21 5:14 PM, John Devitofranceschi wrote:
>>> I can see that “AllowTGTSessionKey” is set to ‘1’ in the virtual registry.
>>>
On Sep 18, 2021, at 12:50 AM, Greg Hudson wrote:
>
> On 9/17/21 5:14 PM, John Devitofranceschi wrote:
>> I can see that “AllowTGTSessionKey” is set to ‘1’ in the virtual registry.
>> Is that not sufficient? Any way around this?
>
> The current documentation of AllowT
So, we’re trying to get kfw-4.1 working in a development environment that’s
using Microsoft App V to deliver applications in a virtual format.
In general things are working, but ms2mit is giving the "Initial tgt’s are not
available from the MS LSA” error
I can see that “AllowTGTSessionKey” is
Has anyone ever developed a way to monitor/report on ccache file read access?
It seems like one could do something clever with auditd on Linux, but I’d be
interested in hearing any war stories folks might have about this sort of thing.
jd
smime.p7s
Description: S/MIME cryptographic signatur
What are the risks of using ms2mit to create an API: ccache? What are the
risks of setting “allowtgtsessionkey” to ‘1’ in the registry (as KfW does)?
I’m interested in setting up ssh ticket forwarding with PuTTY + the MIT gss DLL
provided by KfW (4.1) without having to deal with setting unconst
How long has it been since this happened?
I think that the clients will be fine once their old ccaches expire. Have you
tried forcing the issue by manually refreshing one of the clients?
Sent from my iPhone
> On Jul 22, 2019, at 06:22, Laura Smith
> wrote:
>
> Ok, I hold my hand up, I mess
On Jan 13, 2019, at 1:49 AM, Greg Hudson wrote:
>
> On 1/11/19 11:08 AM, Yegui Cai wrote:
>> Any plan to add the capability of expiring admin sessions into a future
>> release?
>
> We can consider it, although it would come at a complexity cost in the
> network code. Can you describe why that
> On Sep 29, 2018, at 11:33 AM, Greg Hudson wrote:
>
> On 09/28/2018 07:24 AM, John Devitofranceschi wrote:
>> Are there any timing considerations when purging the old master key(s)?
>> I experienced some problems after following the documented procedure
>>
Are there any timing considerations when purging the old master key(s)?
I experienced some problems after following the documented procedure
(kadmind/kpropd not working, tickets not being issued) which I think might have
been due running the ‘purge_mkeys' before the updated principals were
pr
> On Sep 22, 2018, at 10:39 AM, Greg Hudson wrote:
>
> On 09/22/2018 09:44 AM, John Devitofranceschi wrote:
>> In order to remedy this, we tried using a pre-mistake backup (dump format)
>> of the kdb to restore the principals:
>> kdb5_util load -update dumpfil
This week about 100 host and other service principals were deleted by mistake,
rendering the owning systems and services unusable.
In order to remedy this, we tried using a pre-mistake backup (dump format) of
the kdb to restore the principals:
kdb5_util load -update dumpfile principal
Ho
I’m thinking about securing Kerberos administrative principals (*/admin and the
like) with OTP using RADIUS.
Will kadmin take kindly to that?
I have all the parts (RADIUS server, KDC, etc). I just need to glue them
together, but it would be nice to know first if it’s worth the effort.
Tha
Has an environment variable for client flags ever been considered?
The specific use case I’m thinking about is a situation where a user may want
to override a system-wide configuration without the overhead of managing their
own KRB5_CONFIG file.
Example: krb5.conf specifies that forwardable tic
> On Apr 17, 2017, at 16:09, Ramaiah, Vanna G. wrote:
>
> Where can I find the password change logs in Kerberos server?
>
The kadmind logs will show you when passwords are changed.
jd
smime.p7s
Description: S/MIME cryptographic signature
Ker
> On Aug 10, 2016, at 11:29 AM, Michael Howe wrote:
>
> Hi Greg,
>
> On Mon, Aug 08, 2016 at 01:39:49PM -0400, Greg Hudson wrote:
>> On 08/05/2016 02:48 PM, Michael Howe wrote:
>>> When a client has an existing (forwardable) ticket, and the krbtgt is
>>> rekeyed with -keepold, most things keep
Might it be the case that administrative account unlocking using kadmin
(modprinc -unlock princname) will fail in some cases if the version of kadmin
is not sufficiently modern?
For example, kadmin from 1.8.2 can be used to a unlock a principal on a 1.13.2
master, but not when the principal is
> On Jul 29, 2015, at 5:46 PM, Todd Grayson wrote:
>
> Hi,
>
> Is there any general wisdom out there about mixed KDC/Client versions? Are
> there concerns around allowing environments drift to where a KDC would be
> on a later release than the clients?
>
There was this one:
http://krbdev.m
> On Jul 17, 2015, at 9:13 AM, Simo Sorce wrote:
>
> - Original Message -
>> From: "John Devitofranceschi"
>>
>> How long does it take for the stored session keys to expire after the ccache
>> is destroyed? Is it based on ticket lifetime?
We just finished updating our KDC infra to 1.13.2 and I noticed this today.
It was a very quiet day and, after a test "kproplog -R" on the master to make
sure iprop_resync_timeout was sufficient (it was) all the slaves did two
FULL_RESYNCs (I know why; I'm looking forward to 1.14) and then a cou
> On Jul 10, 2015, at 10:06 AM, Simo Sorce wrote:
>
>
> The same is for Kerberized NFS in Linux, the session keys are stored in
> the kernel and there is currently no way to revoke them, however once
> the session is destroyed the kernel will not be able to recreate it.
>
How long does it ta
> On Jun 30, 2015, at 12:56 PM, Greg Hudson wrote:
>
> On 06/27/2015 02:18 AM, John Devitofranceschi wrote:
>> It seems that the 1.8.2 dump file claims to be ipropx, but it still only has
>> the old-style policy records and that makes the 1.13.2 kpropd’s resync fail
We are upgrading our infra to 1.13.2 and I noticed that kpropd fails when
receiving a full sync.
We are upgrading the slaves first and the master last.
It seems that the 1.8.2 dump file claims to be ipropx, but it still only has
the old-style policy records and that makes the 1.13.2 kpropd’s r
> On Jun 20, 2015, at 11:15 AM, John Devitofranceschi
> wrote:
> ...
> It seems that this can be done by kinit’ing against all the KDCs as the
> target principal like this and checking the error message:
>
> echo “” | kinit princ 2>&1 | grep revoke => account i
I find myself needing to implement principal password lockout (standard setup
with 1.13.2 w/8 KDCs)
The powers that be want us to implement self-service account unlocking (w/out
password changing)
We have a password self-service portal and we would like for it to be able to
detect if accounts
How is ktadd *supposed* to figure out which enctype(s) to use?
I am seeing an issue where kadmin’s ktadd, if left to its own devices, will
generate a key with an encryption type that has nothing to do with the KDC’s
supported_enctype list and ktadd seems to completely ignore the local client’s
> On Mar 10, 2015, at 5:47 PM, John Devitofranceschi wrote:
> ...
> In my case, the first wildcard is the second component, so I've just realized
> that my acl line *should* have read:
>
> host/*@MYREALM.COM x */*2...@myrealm.com
>
> which works as expected. I
>
> I just realized that there was not much in the way of context from my
> original message, so here is what I'm trying to do:
>
> If I want to allow the host principal for a given system to manage other
> hostname-based principals for the same host (to enable some kind of
> automation, say),
> On Mar 7, 2015, at 3:17 PM, John Devitofranceschi wrote:
>
>
>> On Jul 17, 2014, at 7:45 PM, Kenneth MacDonald
>> wrote:
>>
>> Quoting John Devitofranceschi on Thu, 17 Jul 2014
>> 15:51:06 -0400:
>>
>>>
>>>> On Jul 17
> On Jul 17, 2014, at 7:45 PM, Kenneth MacDonald
> wrote:
>
> Quoting John Devitofranceschi on Thu, 17 Jul 2014
> 15:51:06 -0400:
>
>>
>>> On Jul 17, 2014, at 12:37, Greg Hudson wrote:
>>>
>>>> On 07/16/2014 06:34 PM, John
> On Jul 17, 2014, at 12:37, Greg Hudson wrote:
>
>> On 07/16/2014 06:34 PM, John Devitofranceschi wrote:
>> host/*@MYREALM.COM x */*1...@myrealm.com
>
> This works for me in 1.11, 1.12, and the master branch. So, your
> expectation isn't unreasonable, but I&#x
If I want to allow the host principal for a given system to manage other
hostname-based principals for the same host (to enable some kind of automation,
say), based on the documentation, I would expect that an entry in kadm5.acl
that looks like this:
host/*@MYREALM.COM x */*1...@myrealm.com
w
On Apr 20, 2014, at 9:40 AM, John Devitofranceschi wrote:
>
> After we upgraded our KDC from 1.8.2 to 1.11.3, we found that the older
> Solaris systems' native kinit started core dumping.
>
> Initially, the clients have no default entypes defined, or they might have
&g
After we upgraded our KDC from 1.8.2 to 1.11.3, we found that the older Solaris
systems' native kinit started core dumping.
Initially, the clients have no default entypes defined, or they might have
des-cbc-crc and des3-cbc-sha1 defined.
The core dumps stop when we define des-cbc-crc as the on
On Jul 31, 2013, at 5:05 AM, Andreas Hauffe
wrote:
> Yes, it is a OpenSuSE 12.3 client. So this means, this is a completely normal
> behaviour?
>
> Andreas
>
> Am Mittwoch, 31. Juli 2013, 10:01:20 schrieb moritz.will...@ubs.com:
>> I assume this is a Linux client? Yes, the security context e
When upgrading from MIT Kerberos 1.X to 1.X+N what kind of general rules of
thumb can one rely on in terms of compatibility?
Should the slave KDCs be upgraded first, then the master? Or upgrade the
master first?
Any considerations when using incremental v. full propagation?
When upgrading
On Feb 13, 2013, at 11:21 AM, Nico Williams wrote:
> On Wed, Feb 13, 2013 at 6:12 AM, John Devitofranceschi
> wrote:
>> One thing that we do is monitor propagation. Something like:
>>
>> lpc=get_last_princ_changed;
>>
>> master_lpc_kvno=get_kvno(maste
On Jan 15, 2013, at 9:58 AM, Nico Williams wrote:
> On Tue, Jan 15, 2013 at 12:38 AM, Roland C. Dowdeswell
> wrote:
>> And [to the MIT developers], I think that it would be nice if there
>> were either (1) functionality within Kerberos which allowed for
>> the writing of programs such as this
I was hoping to get an opinion on this. Maybe it's something that's been seen
before.
I see this in the kadmind log:
Feb 7 17:00:10 server.realm.com kadmind[17670]: [ID 702911 local0.notice]
Request: kadm5_create_principal, bar...@realm.com, Cannot lock database,
client=f...@realm.com, serv
te ]; then
>
># output that the principal is expired
>echo "$line is expired on $expdate";
> else
>
># output that the principal will expire on $expdate
>echo "$line is valid till $expdate&quo
Are there any tools that would allow someone to generate reports from the KDC
(or the local principal file) which answer questions like:
Which principals are expired?
Which principals have expired passwords?
Which principals have passwords that will expire in N days?
Which principals have pol
Sent from my iPhone
On Mar 30, 2012, at 12:41, Nico Williams wrote:
> On Fri, Mar 30, 2012 at 8:05 AM, John Devitofranceschi
> wrote:
>> On Mar 30, 2012, at 8:23, Ken Hornstein wrote:
>>
>>>> Does this mean that in order to consider one's KDC infra LOA3 c
On Mar 30, 2012, at 8:23, Ken Hornstein wrote:
>> Does this mean that in order to consider one's KDC infra LOA3 compliant
>> one needs to hold the principal database in a compliant hardware
>> security module? Or am I missing something here?
>
> You're in trouble even if you did that anyway. L
I am trying to figure out how the stipulations for the management of tokens and
credentials at LOA3 (Chapter 7.3.1.3 in NIST Special Publication 800-63-1
(http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf) map to a
Kerberos KDC.
They talk about the encryption key for the s
ot;operator/machine1" and then in ldap he has
> his own profile. If he logs in in machine2 he'll get a different ldap
> profile.
>
> Probably as John Devitofranceschi, I could generate keytabs for each user
> and force the authentication with that key. But I do not want t
I think you're not going to be able to do this without a local keytab.
Keep your local keytabs in a consistent place, like
/var/spool/keytabs/LOGINNAME and then, when you log in as LOGINNAME make
certain that KRB5_KTNAME is set to the right keytab in the user's .profile or
the system .profile a
I was wondering if there was any more clarity to be had around 'issue 3' here.
I am interested in a reliable way to detect this error condition on the slave
server itself (or even reproducing it).
Or is figuring out if an update *should* have come in and then seeing that it
didn't is the only w
at 10:18 PM, Greg Hudson wrote:
> On Sat, 2011-05-21 at 10:28 -0400, John Devitofranceschi wrote:
>> We've run into a situation with MIT Kerberos 1.8.2 where the master
>> key has been changed and yet the slave kdc's are still reporting that
>> the original master
We've run into a situation with MIT Kerberos 1.8.2 where the master key has
been changed and yet the slave kdc's are still reporting that the original
master key is being used on new principals.
Slave kdc updates are happening via iprop.
The master kdc is behaving as expected, and all
I just noticed the SecurID Preauth Support plugin in MIT Kerberos 1.9 and I was
wondering if anyone has been using it yet.
I am specifically interested in the operational and user aspects of supporting
this plugin.
>From the plugin's Readme:
"Once the plugin is installed, set the requires_pr
We're upgrading our KDCs to 1.6.1 and I've just noticed that WRQ
Reflection's Kerberos Manager does not seem to properly authenticate.
I get the message "Integrity check failed. Wrong password or message
tampered with. (KRB010)"
Has anyone seem this before?
Thanks in advance for any help,
53 matches
Mail list logo
