-----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.