I used to think that I can limit kinit by client address for certain
principal, using a preauth plugin. The plugin can check the client
address against one of principal's string attribute, such as
"allowfrom", preventing keytab theft in an automation environment.
That's just an idea that I didn't i
Hello,
I see that there are recent pull requests on the GitHub mirror for MIT Kerberos
(https://github.com/krb5/krb5). Do you prefer to receive bug reports
accompanied by proposed patches there, or still in RT via krb5-b...@mit.edu?
Thanks,
--
Richard
__
[This discussion might be more appropriate for krb...@mit.edu as it
pertains to MIT krb5 development, but I will answer here.]
On 04/19/2017 08:14 AM, Richard Silverman wrote:
> I see that there are recent pull requests on the GitHub mirror for MIT
> Kerberos (https://github.com/krb5/krb5). Do yo
github is our preferred avenue for patches, while krb5-b...@mit.edu is
still our preferred avenue for bug reports... in the specific case of
your recently submitted bug report (#8579), I think some careful
analysis of the bug will be required before we know the appropriate
design for the fix, so
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
Hi,
We have been using the kerberos 1.10.3 library and we find that
occasionally a lot of the following files are kept open by the library
and they fill up the fd limit of the process,
lsof output
--
myproc 8777 nutanix 254u REG 9,1 7048537432
/var/tmp/krb5_RCWZN1Er
