On Jun 9, 2010, at 17:36, Richard E. Silverman wrote:
>> "res" == Richard E Silverman writes:
>
>res> One day, due to an error, the number of KDC SRV records for one
>res> of our realms doubled from 27 to 54... and KDC lookups via DNS
>res> prompty broke. I bumped up the nextincr
I'm pleased to announce release 4.3 of pam-krb5.
pam-krb5 is a Kerberos v5 PAM module for either MIT Kerberos or Heimdal.
It supports ticket refreshing by screen savers, configurable authorization
handling, authentication of non-local accounts for network services,
password changing, and password
In 1.8.1, there is the following code in src/lib/krb5/os/dnsglue.c:
krb5int_dns_init(struct krb5int_dns_state **dsp,
char *host, int nclass, int ntype)
{
...
nextincr = 2048;
maxincr = INT_MAX;
...
One day, due to an error, the number of KDC SRV records
> "res" == Richard E Silverman writes:
res> In 1.8.1, there is the following code in
res> src/lib/krb5/os/dnsglue.c:
res>krb5int_dns_init(struct krb5int_dns_state **dsp, char *host,
res> int nclass, int ntype) { ... nextincr = 2048; maxincr = INT_MAX;
res> ...
r
On Wed, Jun 09, 2010 at 12:15:36PM -0400, Greg Hudson wrote:
> I think the most practical fix for your problem is to make the Heimdal
> KDC more forgiving--it should not squash the validity end time of the
> ticket simply because it calculated a lower maximum renewable end time.
Thanks for the mor
[resend with proper tagged From address]
On Wed, Jun 09, 2010 at 12:15:36PM -0400, Greg Hudson wrote:
> I think the most practical fix for your problem is to make the Heimdal
> KDC more forgiving--it should not squash the validity end time of the
> ticket simply because it calculated a lower maxim
9 jun 2010 kl. 09:15 skrev Greg Hudson:
> I think the most practical fix for your problem is to make the Heimdal
> KDC more forgiving--it should not squash the validity end time of the
> ticket simply because it calculated a lower maximum renewable end time.
> If I were a Heimdal developer, I'd p
On Mon, 2010-05-17 at 19:37 -0400, Richard Johnson wrote:
> I've found a misbehavior and what looks like a bug in clients behavior under
[...]
Hi, sorry it's taken several weeks to look into this. I believe you
have one fundamental misunderstanding about your situation, and it comes
here:
> When
