[33506] in Kerberos
Re: Database locking during kprops, MIT 1.8
daemon@ATHENA.MIT.EDU (John Devitofranceschi)
Wed Jun 22 18:04:00 2011
Date: Wed, 22 Jun 2011 18:01:52 -0400
From: John Devitofranceschi <jdvf@optonline.net>
In-reply-to: <30876573.1286847423900.JavaMail.root@safetgram>
To: Jeremy Hunt <jeremyh@optimation.com.au>, kerberos@mit.edu
Message-id: <9655DCF6-A5CD-43D3-ACEB-C203D1DB5E49@optonline.net>
MIME-version: 1.0
Content-Type: multipart/mixed; boundary="===============0265183632=="
Errors-To: kerberos-bounces@mit.edu
--===============0265183632==
Content-type: multipart/signed; boundary=Apple-Mail-1--239569302;
protocol="application/pkcs7-signature"; micalg=sha1
--Apple-Mail-1--239569302
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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 way?
With respect to the policy propagation issue, I found that modifying a =
slave's copy of the principal database by creating a bogus principal (or =
something) with kadmin.local will force a full propagation in an =
otherwise healthy server. This seems pretty effective, but is it safe?
jd
On Oct 11, 2010, at 9:36 PM, Jeremy Hunt wrote:
> Hi Ken, Dominic et al,
>=20
> Sorry about using the term "second issue" twice. I will clarify all =
points as Ken raised them
>=20
> Issue1: profile changes do not appear to be logged and propagated via =
iprop.
>=20
> I am sorry, I meant "policy" not "profile". Probably because I meant a =
user profile, where a user is tied to one or more policies. A policy in =
kerberos is a bunch of attributes that are linked by a name so certain =
types of user can be given consistent sets of attributes.
>=20
> I originally read this document =
http://k5wiki.kerberos.org/wiki/Projects/Lockout, which is a discussion =
on how to provide a principal lockout functionality in kerberos similar =
to AD and LDAP. It is very interesting. It points out that some =
attributes of principals are not replicated, surprisingly these include =
last successful login, lastfailed login and failed authentication =
counts. This would encourage a lot of readers of this list to revisit =
their pasword lockout policy if they have one. However read on.
>=20
> My own experiments found that:
>=20
> * locked out principals were propagated as lockouts by the =
"kiprop" process.
> * policies were not propagated, however principals referring to the =
policies were propagated
>=20
> For example I created a lockout policy and linked it to my principals. =
My principal changes were propagated, but I had to create a lockout =
policy separately on the slave. the actual "kadmin" commands were
> adpol lockout
> modpol -maxfailure 4 lockout
> modprinc -policy lockout principal17
> Thenceforth "getprinc principal17" had a line "Policy lockout", even =
on KDCs that did not have the lockout policy defined.
>=20
> I also found with a full propagation the policy was carried across. =
Full propagation is a database dump, remote copy of dump and load of =
dump on the replica server(s). Incremental propagation copies log =
changes and updates the database from the new entries since the last log =
time stamp on the replica server.
>=20
> I would agree this is not a bug, just something to know. As part of my =
setup I create a new master KDC, setup the database from a dump of the =
old database, make any required changes (the kdc names might have =
changed), dump the database again and finally load the new dump on my =
replica(s).
>=20
> Issue 2: occasionally iprop gets lost and decides to do a full =
propagation, for that scenario you will get your timeouts, but it will =
be a lot less frequent than what you are currently getting.
>=20
> Ken is right, this is designed not to happen. I was actually able to =
force it by putting a much higher load of updates on my test systems =
than production would ever see, and my test systems were hopelessly =
under configured. If you were considering incremental propagation, then =
you might want to do similar tests.
>=20
> Issue 3. it is documented as losing connectivity occasionally and so =
may need to be restarted.
>=20
> I found a reference to this in a proviso in the kerberos install =
document provided online by MIT in "Incremental Database Propagation" =
Section:
> =
http://web.mit.edu/Kerberos/krb5-1.8/krb5-1.8.3/doc/krb5-install.html#Incr=
emental%20Database%20Propagation
>=20
> At the end of this section it refers to several known bugs and =
restrictions in the current implementation, the first of which is:
>=20
> * The "call out to |kprop|" mechanism is a bit fragile; if the =
|kprop| propagation fails to connect for some reason, the process on the =
slave may hang waiting for it, and will need to be restarted.
>=20
> I was unable to cause this in my testing and would be interested to =
know more about it. The interim solution would be to restart kpropd on =
the replica server, maybe after checking the timestamp on the =
propagation log (as a cron job perhaps).
>=20
> Regards,
>=20
> Jeremy Hunt
>=20
> On 12/10/2010 8:02 AM, Ken Raeburn wrote:
>> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>>=20
>>=20
>> On Oct 10, 2010, at 19:46, Jeremy Hunt wrote:
>>> Hi Dominic,
>>>=20
>>> Thanks for your feedback. You make a good point about reporting a =
bug. Though my memory is that the Kerberos team knew about them all..
>>>=20
>>> The second issue is as designed, and given that kprop is so =
efficient, isn't as bad as I first thought when I read about it. Of =
course your experience does show its downside.
>>>=20
>>> The second issue is reported in the Kerberos team's own =
documentation. Like I said I haven't seen it, ... yet. I reported it =
because they have and you might miss the warning.
>> I assume one of these is meant to say "third issue"?
>>=20
>> The occasional need for kprop is basically only if iprop fails for =
long enough that the on-disk queue of changes overflows its configured =
size (which might just be hard-coded, I forget). Unless you're making =
changes to large numbers of principals at once or losing connectivity =
for extended periods, it ought not to happen much. And if you're =
changing most of your principals at once, a full kprop is probably more =
efficient anyways.
>>=20
>> (I don't recall the occasional-losing-connectivity issue offhand, =
despite having worked with this code before when I was at MIT, but I'm =
at my non-Kerberos-hacking job at the moment and don't have time to look =
it up; maybe later.)
>>=20
>>> The first issue, I assumed the kerberos development team already =
knew of. I will have to go back and look at my notes, but I thought I =
saw something in the code or the documentation that made me think they =
knew about it and it wasn't an easy fix. Certainly it behoves me to =
revisit this and to report it as a bug if my memory is wrong. Like I =
say, it is an observation that operationally does not affect us, btw a =
full dump/restore a la kprop will take across profiles.
>> It's not clear to me what you mean by "profile changes". At least =
internally, we use "profile" to refer to the configuration settings from =
the config files. Such things aren't and never have been recorded in =
the database nor automatically propagated between KDCs by any means in =
the Kerberos software; some of the settings are required to be =
consistent between KDCs for consistent operation, but others only affect =
the KDC making changes to the database. If this isn't what you're =
referring to, please do explain.
>>=20
>> Ken
>> ________________________________________________
>> Kerberos mailing list Kerberos@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>=20
>=20
>=20
> --=20
>=20
> "The whole modern world has divided itself into Conservatives and =
Progressives. The business of Progressives is to go on making mistakes. =
The business of the Conservatives is to prevent the mistakes from being =
corrected." -- G. K. Chesterton
>=20
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--Apple-Mail-1--239569302--
--===============0265183632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============0265183632==--
