Database locking during kprops, MIT 1.8

[Jeremy Hunt]

  Hi Ken, Dominic et al,

Sorry about using the term "second issue" twice. I will clarify all points as Ken raised them

Issue1:  profile changes do not appear to be logged and propagated via iprop.

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.

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.

My own experiments found that:

    *   locked out principals were propagated as lockouts by the "kiprop" process.
    * policies were not propagated, however principals referring to the policies were propagated

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.

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.

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).

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.

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.

Issue  3. it is documented as losing connectivity occasionally and so may need to be restarted.

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#Incremental%20Database%20Propagation

At the end of this section it refers to several known bugs and restrictions in the current implementation, the first of which is:

    * 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.

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).

Regards,

Jeremy Hunt

On 12/10/2010 8:02 AM, Ken Raeburn wrote:
> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>
>
> On Oct 10, 2010, at 19:46, Jeremy Hunt wrote:
>> Hi Dominic,
>>
>> 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..
>>
>> 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.
>>
>> 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"?
>
> 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.
>
> (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.)
>
>> 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.
>
> Ken
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>


-- 

"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