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
>> > >dns lookup could give me a domain controller overseas which will be
>> > >or maybe even a domain controller that isn't responding. As such, I
>> > >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
>> > >results. My initial id request is very slow but seems to produce
>> > >While searching, it seems to also be 'inserting' users into the
>> > >table - almost as if it's searching and inserting our entire user
>> > >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
>> > >
>> > >As my initial id request returns, it seems to return several chunks of
>> > >group ids at once as if it's processing them individually and
>> > >users in that group (thus the above log entries).
>> > >
>> > >Not sure if this helps or just muds up the issue but it's strange
>> > >
>> > 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
>> > with option ad_site.
>> I've got something to add to this, some behaviour we're seeing with
>> CentOS 7 servers using sssd-ad.
>> 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
>> In what circumstances would sssd prefer a backup server to a primary server?
>> I've got a chunk of log which I've anonymised:
> The issue is here:
> 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 Beranek To generalise is to be an idiot.