suggestion for locating master kdc logic

Will Fiveash will.fiveash at
Sat Apr 7 15:51:39 EDT 2012

On Sat, Apr 07, 2012 at 10:03:19AM -0400, Sam Hartman wrote:
> >>>>> "Will" == Will Fiveash <will.fiveash at> writes:
>     Will> On Fri, Apr 06, 2012 at 04:45:08PM -0400, Sam Hartman wrote:
>     >> Looking for kpasswd_server is a bad idea because of AD.  In
>     >> practice it doubles the number of account lockout attempts when
>     >> you give a bad password.
>     Will> I forgot about the account lockout issue however it seems like
>     Will> that issue also applies to trying admin_server in an
>     Will> environment where KDCs are enforcing account lockout policies.
>     Will> In either case, setting my proposed try_admin_server_on_err
>     Will> (or whatever it should be called) to false would limit fall
>     Will> back to just master_kdc, if it existed.
> I am opposed to this change.  I'm particularly opposed to a version of
> the change that considers kpasswd_server.

That's fine, let's take kpasswd_server off the table.  In another e-mail
I wrote up my reasoning stating (tweaked for clarity):

"Mulling this over more, given this (the master_kdc change) is a change
 to previously default behavior that some may be relying on to deal with
 KDB propagation delay, I think the thing to do is introduce a new
 config parameter that allows the admin to change the default behavior
 so that admin_server is not used as a fall back when a krb error
 message is returned for a AS/TGS_REQ.  Then those that found the
 default behavior objectionable could change it."

Are you opposed solely because because of AD account lock out?

Will Fiveash
Oracle Solaris Software Engineer
Sent using mutt, a sweet, text based e-mail app <>

More information about the krbdev mailing list