Thanks very much for the help and insights. Unfortunately we may have to return the machine back to the customers soon. I will try to get more info before then. We may leave domain logging @ 5 and return to them. Will have to bounce off my colleagues.
we may also try the "cache_credentials = True" directive
If we do have to turn over, will report back

Thanks again for the explanations
best regards

On Tue, Jan 24, 2017 at 10:00 AM, Lukas Slebodnik <lslebodn@redhat.com> wrote:
On (23/01/17 14:41), jsl6uy js16uy wrote:
>Unfortunately we haven't seen any new issues since turning debug under the
>domain section to 9.
You can try to decrease level to (e.g. 5)

>So when sssd shutdowns down and restarts due to missing "pings" to the
>service named after the domain, should we be blocked on access?
pam_sss is very simple. All logic in daemon part. And If daemon
demon is busy with some task it cannot process authentication.
That's the reason why it would be good to see log files to find out
what was going there,

>We understand for sec reasons its often times better to fail closed, like a fw
>breaking but locking/closing all ports, but what about if a user is
>leveraging this on his laptop? remotely and/or on wifi? I would expect the
>last local copy of the sss database/cache should be used to let them login
>During this process when sssd shuts down, its not like its removing the
>cache under /var/lib/sss/db.
That should work with "cache_credentials = True" in domain section.
e.g. which is standard use-case for laptops.

>Should we ever see a point where sssd won't let you login due to the domain
>service timeout?
>
From security point of view it's better to block the access If you are not in
known state (online, offline). Otherwise users might be able to authenticate
even though the access should be denied. (access was disabled on AD
but sssd_be is for some reason unresponsive/busy and cannot detect it)

This is a reason why it would be good to find out why sssd_be was unresponsive.

LS
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org