-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/02/2014 07:41 AM, Jakub Hrozek wrote:
On Wed, Apr 02, 2014 at 12:02:41PM +0300, "Thomas B.
Rücker"
wrote:
> Hi,
>
> we're using SSSD in combination with active directory and have
> received complaints from users about a corner case in our setup.
>
> Our AD servers are only reachable from within our corporate
> network, connection attempts from the outside are dropped by
> firewalls. This leads to the following scenario: - user takes
> machine (e.g. laptop) outside the corporate network - user tries
> to authenticate (or in some cases also tries to "ls" which causes
> uid/gid lookup) - sssd will try to reach the configured servers
> for up to 30s
^^^^^^^^^^^ This is not so clear to me, are you saying that it
takes up to 30 seconds for SSSD to realize it's offline and switch
to the offline mode?
> - sssd goes (back) into offline mode and uses cached credentials
> and authenticates the user
I'm using a very similar setup on my laptop where I authenticate
against LDAP and Kerberos servers inside Red Hat's internal
network. I see a couple of seconds lag sometimes, but not 30s as
you describe..
What he's saying is that the firewall behavior from outside the
network is DROP. In our case, the address isn't even resolvable from
outside, since we use private DNS entries. So we have a short-circuit.
In his situation, the address is resolvable, so SSSD sends a request
to connect to LDAP. It then hangs with no response.
Now, this *should* be hitting the 6 second ldap_network_timeout
default value. I'm not sure why it's not, unless there's a timeout
failure happening during connect() instead of during poll/select,
which I don't think we can actually avoid.
<snip>
Can you enable debugging and see where the biggest lag is? Maybe
we could see what exactly takes the longest and lower the
appropriate timeout.
This would be very helpful. Please set 'debug_level = 7' in the
[domain/DOMAINNAME] section of sssd.conf, restart SSSD and then gather
the logs. Look at the timestamps to see what is happening for about
thirty lines before and after the lag. Ideally, sanitize that log and
send it to us.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlM8AmEACgkQeiVVYja6o6MrWQCgm1/kOZ5g9sePtV0o+k4Cs7D8
TyIAoIcJDpCmTbLPZGrqW8KebdiGMacz
=xKtv
-----END PGP SIGNATURE-----