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 <abhisheyk...@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 <sb...@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-le...@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-le...@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-le...@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-le...@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
