On 11 September 2017 at 14:28, Jakub Hrozek wrote:
> On Mon, Sep 11, 2017 at 12:23:26PM +0100, John Beranek wrote:
>> On 1 September 2017 at 15:54, Lukas Slebodnik wrote:
>> >
>> > On (01/09/17 09:33), William Edsall wrote:
>> > >Had a few communications with Michal but we're still stuck.
>> > >
>> > >One issue is that we have dozens of domain controllers globally. A
standard
>> > >dns lookup could give me a domain controller overseas which will be
slow,
>> > >or maybe even a domain controller that isn't responding. As such, I
have
>> > >been inserting ad_server = x into the sssd.conf to improve performance.
>> > >
>> > >I noticed that if I do not insert ad_server = x, I'm getting
different
>> > >results. My initial id request is very slow but seems to produce
results.
>> > >While searching, it seems to also be 'inserting' users into the
users hash
>> > >table - almost as if it's searching and inserting our entire user
database?
>> > >For example there are countless lines of the following:
>> > >(Fri Sep 1 09:28:37 2017) [sssd[be[example.com]]]
>> > >[sdap_nested_group_hash_insert] (0x4000): Inserting
>> > >[CN=user_name,OU=bla,OU=bla Users,DC=dow,DC=com] into hash table
[users]
>> > >
>> > >As my initial id request returns, it seems to return several chunks of
my
>> > >group ids at once as if it's processing them individually and
searching all
>> > >users in that group (thus the above log entries).
>> > >
>> > >Not sure if this helps or just muds up the issue but it's strange
indeed.
>> > >
>> > You needn't hardcode ad_server. You can still rely on dns discovery.
>> > I assume you use sites in AD. So you can "pin" sssd to your
local/nearest site
>> > with option ad_site.
>>
>> I've got something to add to this, some behaviour we're seeing with
>> CentOS 7 servers using sssd-ad.
>>
>> sssd-1.14.0-43.el7_3.18.x86_64
>> sssd-ad-1.14.0-43.el7_3.18.x86_64
>> sssd-client-1.14.0-43.el7_3.18.x86_64
>> sssd-common-1.14.0-43.el7_3.18.x86_64
>> sssd-common-pac-1.14.0-43.el7_3.18.x86_64
>> sssd-ipa-1.14.0-43.el7_3.18.x86_64
>> sssd-krb5-1.14.0-43.el7_3.18.x86_64
>> sssd-krb5-common-1.14.0-43.el7_3.18.x86_64
>> sssd-ldap-1.14.0-43.el7_3.18.x86_64
>> sssd-proxy-1.14.0-43.el7_3.18.x86_64
>>
>> In our case we have some DCs which are located at a partner site, and
>> are therefore inaccessible to clients on our standard LANs.
>>
>> When SSSD starts it will correctly determine there are 2 primary DCs
>> (these are the ones for the site) and 7 backup DCs.
>>
>> However, what is happening from time to time is that for some reason
>> I've not yet determined the connection(s) to the primary DC(s) are
>> dropping, and then sssd attempts to connect to one of the DCs that are
>> inaccessible.
>>
>> In what circumstances would sssd prefer a backup server to a primary server?
>>
>> I've got a chunk of log which I've anonymised:
>>
>>
https://paste.fedoraproject.org/paste/G69lC9COQfbnWFI~qtFLZw
>
> The issue is here:
[snip]
>
> So this is a known bug where locating the site (even though we know it
> already) can contact the DCs outside that site.
>
> In the meantime, until the fix is released, you can hardcode the site
> using the 'ad_site' option.
Thank you Jakub, is there a ticket/BZ for this? I noticed after my
post that it's evident on CentOS 6 too.
?
John
--
John Beranek To generalise is to be an idiot.