[PATCH] LDAP: Only use paging control on requests for multiple entries
by Stephen Gallagher
The paging control can cause issues on servers that put limits on
how many paging controls can be active at one time (on some
servers, it is limited to one per connection). We need to reduce
our usage so that we only activate the paging control when making
a request that may return an arbitrary number of results.
This is the first step to solving
https://fedorahosted.org/sssd/ticket/1202 but I wanted to get this patch
on the list immediately since it changes the semantics of
sdap_get_generic_send() (and is therefore likely to need merging with
other in-progress patches).
Please review immediately.
I am still working on the second half of the fix for 1202, which will
involve serializing requests that require the paging control to ensure
that we only run one paged request at a time.
12 years, 1 month
Re: [SSSD] Headsup! krb5 ccache defaults are changing in Rawhide
by Stephen Gallagher
On Thu, 2012-02-23 at 12:59 -0700, Stephen John Smoogen wrote:
> On 23 February 2012 12:28, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> > Dear fellow developers,
> >
> > with the upcoming Fedora 18 release (currently Rawhide) we are going to
> > change the place where krb5 credential cache files are saved by default.
> >
> > The new default for credential caches will be the /run/user/<username>
> > directory.
>
> I am going to ask something probably obvious but not what I could
> easily google. The sssd can be configured to cache tickets for a
> weekend or such in this case. The usage we usually ran into was:
>
> 1) Users can only log into laptops if able to communicate with AD/KRB
> servers or if a valid local ticket still existed.
> 2) User would turn off laptop and go home.
> 3) User would work from home and get a refreshed/new ticket when they
> got the VPN up. [If they didn't.. then they could not log in again
> after the ticket expired.]
This is just plain wrong. If that was happening, it was a bug in SSSD.
If we can't reach the Kerberos server, we'd authenticate against the
local cache (assuming that cached_credentials = True in sssd.conf). If
they also have krb5_store_password_if_offline = True, then the
credentials should automatically be updated when the VPN comes up as
well. (In the interim, we generate a fake credential cache file that
contains tickets that expired at the start of the epoch, so that
krb5-auth-dialog or manual kinit and the like will behave
appropriately).
The current validity status of the Kerberos ticket is completely
irrelevant to successful login. For the record, I've been
using /run/user/sgallagh/krb5cc for over a month now, and I've never
once had an issue authenticating with my cached credentials while
logging in at home, nor have I had an issue with the automatic deferred
kinit updating my tickets when I VPN in.
>
> In the Linux side the existance of a ticket in /tmp allowed this to
> work... but not sure how it would work in current environment.
>
> The above is probably "broken" in various ways that I don't know.. but
> was how a couple large work places had been set up.
>
12 years, 1 month