Are you sure Kerberos auto-discovery is working correctly?  I was just in /var/log/sssd/ssd_$domain.log file yesterday (checking on site awareness) and I figured out how to check for proper auto-discovery.

First off, you have to set:
   dns_lookup_kdc = true 
in /etc/krb5.conf file or leave this setting unset.  ("true" is the default).  The point is, you can't have:

dns_lookup_kdc =false

Next you have to set up your SRV records in DNS.  Certainly _ldap._tcp.ad.example.com.   For you, you probably don't care about _gc._tcp.ad.example.com.  

So then if that's all set up, start sssd with debug_level = 9 in your domain section of sssd.conf file.  You should see in sssd_$domain.log file lines like:

(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_discover_srv_done] (0x0400): Got answer. Processing...
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_discover_srv_done] (0x0400): Got 11 servers
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_discover_servers_primary_done] (0x0400): Looking up backup servers
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'example.com'
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.example.com'
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [resolv_getsrv_done] (0x1000): Using TTL [51]
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [request_watch_destructor] (0x0400): Deleting request watch
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_discover_srv_done] (0x0400): Got answer. Processing...
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_discover_srv_done] (0x0400): Got 109 servers
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [ad_srv_plugin_servers_done] (0x0400): Got 11 primary and 109 backup servers
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'RDUDC16AMER05.example.com:389' to service 'AD'
(Fri Oct 18 14:27:09 2019) [sssd[be[example.com]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'RDUDC12AMER02.example.com:389' to service 'AD'
...

The primary AD controllers are determined from site awareness, looking up your subnet in AD.  The backup servers are any other AD controller found via this _ldap._tcp.example.com SRV lookup.

In your case, I don't think you care about site-awareness.  That's overkill for your one location.  But it should discover your two AD controller in that log file.

Spike  



On Fri, Oct 18, 2019 at 12:26 PM Abhisheyk Deb <abhisheykdeb@gmail.com> wrote:
Thanks for the reply, 

I have tried using the options timeout:2 which seems to be not taking any effect, as the SSH logins are still taking 10 seconds, ( 5 seconds timeout  * 2 attempts) ./etc/resolv.conf file.

I looked into the timeouts link, and i have SSSD version 1.16.2-13 installed on my machine. The only timeouts that are matching are dns_resolver_op_timeout and dns_resolver_timeout out of the four mentioned in the link.

The following is showing up on the man page of sssd-ad on my machine.

"
dns_resolver_op_timeout
           How long would SSSD talk to a single DNS server.
  dns_resolver_op_timeout
           How long would SSSD try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site.
"

So what are default values they are set to right now in my verison, how can I find out? Are the default values for dns_resolver_op_timeout and  dns_resolver_op_timeout respectively.set to 2 and 4 seconds respectively?

Should I increase or lower values, I don't want it timeout early. 

Are there any other ways to solve this problem?

Thank you
Abhishek Deb

On Fri, Oct 18, 2019 at 3:08 AM Sumit Bose <sbose@redhat.com> wrote:
On Thu, Oct 17, 2019 at 04:23:11PM -0400, Abhisheyk Deb wrote:
> Hi.
>
> We have the following setup, CentOS machines which are running 7.3 version
> and we want them to use active directory users for SSH Logins.
>
> The domain ad.example.com which we want to use, has two domain controllers
> with IP addresses of 10.1.2.1 and 10.1.2.2, and both have DNS Servers
> installed on them.
>
> We have the following in the /etc/resolv.conf
>
> search ad.example.com
> nameserver 10.1.2.1
> nameserver 10.1.2.2
>
> We were able to do a join by using the following command:
> realm join ad.example.com
>
> The computer objects are getting created in both domain controllers.
>
> The SSH Logins for the active directory users are also working without any
> issues.
>
> The /etc/sssd/sssd.conf file is as follows:
> [sssd]
> domains = ad.example.com
> config_file_version = 2
> services = nss, pam
>
> [pam]
> offline_credentials_expiration = 1
>
> [domain/ad.example.com]
> ad_domain = ad.example.com
> krb5_realm = ad.example.com
> realmd_tags = manages-system joined-with-samba
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = False
> access_provider = ad
> override_homedir = /user/%u
> account_cache_expiration = 1
> entry_cache_timeout = 180
>
> But when we put the first domain controller down (10.1.2.1) which is the
> first nameserver in /etc/resolv.conf. SSSD is not trying the second domain
> controller (10.1.2.2) at all because when we login, we see the following
> message
>
> "Authenticated with cached credentials, your cached password will expire
> at: Fri Oct 18 19:47:42 2019."
>
> And we are able to ping 10.1.2.2 and the command
> nslookup ad.example.com also gives the following output
>
> Server:         10.1.2.2
> Address:        10.1.2.2#53
>
> Name:   ad.example.com
> Address: 10.1.2.1
> Name:   ad.example.com
> Address: 10.1.2.2
>
> And we have not added any option for ad_server or ad_backup_server in our
> sssd.conf file which I am assuming means that autodiscovery is turned on by
> default.
>
> So should the /etc/resolv.conf only have one nameserver entry, and SSSD
> only reads that, which means the main domain controller needs to running
> always.
>
> What I mainly want to know is that even if one of the Domain Controllers
> are down and SSSD was using it as the primary domain controller for
> authentication requests, can it not fallback to using some other domain
> controllers in the AD Domain.
>
> How can tweak my sssd.conf file for the use case that I want.

Hi,

there are various timeouts involved here and in your version of SSSD they
might not be well aligned.

What oyu can try as a first step is to lower the timeout in
/etc/resolv.conf to e.g. 2s with

    options timeout:2

(I hope SSSD's resolve will pick this value as well). The default here
is 5s and many of the LDAP related timeouts SSSD is using are 6s. So it
might be that waiting for a DNS reply just takes too long so the SSSD
already switches to the offline mode before the second server can be
tried.

For a discussion about the involved SSSD timeouts see
https://github.com/SSSD/sssd/pull/636. Please note that not all options
might be available in sour version of SSSD.

bye,
Sumit

>
> If somebody can give me some advice on this, it would be really helpful,
>
> Thank you
> Abhishek Deb

> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org