[37968] in Kerberos
Re: Limit kinit by client address?
daemon@ATHENA.MIT.EDU (Wang Jian)
Thu Apr 20 07:01:53 2017
MIME-Version: 1.0
In-Reply-To: <a0093160-3ba1-f3da-d2f5-9116a78de37f@mit.edu>
From: Wang Jian <larkwang@gmail.com>
Date: Thu, 20 Apr 2017 19:01:35 +0800
Message-ID: <CAF75rJCAhdaCoVajtWD4hdkObAx3FOqOfSpUtpRERs=waA50bQ@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
2017-04-20 2:09 GMT+08:00 Greg Hudson <ghudson@mit.edu>:
> On 04/19/2017 08:10 AM, Wang Jian wrote:
>> I used to think that I can limit kinit by client address for certain
>> principal, using a preauth plugin. [...]
>
>> Now, we do have such demand. But when I start to implement it, I find
>> that in no way client address can be retrieved from context paramters
>> in plugin.
>
> I think that's true. We could add a callback to retrieve the client
> address. But more importantly, you can't write a kdcpreauth plugin
> module so that it gets consulted independently of the client trying to
> use a specific preauthentication mechanism over the wire.
No catch all? For example
static krb5_preauthtype nacl_pa_types[] = { KRB5_PADATA_AP_REQ, 0 };
Of course, semantically, preauth isn't the best hook point.
> We do have a wishlist item of implementing a pluggable KDC policy
> interface (independent of the KDB module, which already gets to make
> policy decisions). If we did that, and made the client address
> available through that interface, a policy plugin module could make this
> decision.
That's great. The question is, when it will be implemented?
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
