Replied directly with updated logs. There was a DNS issue caused by myself during a frenzy of testing.

On Thu, Aug 31, 2017 at 10:47 AM, Michal Židek <> wrote:
I have the important part of logs now :)

Looking at the domain logs, this looks like a DNS or networking issue.
Are you sure you can resolve the EXAMPLE.EXAMPLE.COM from the machine
with SSSD?

(Thu Aug 31 09:16:17 2017) [sssd[be[]]] [fo_resolve_service_done] (0x0020): Failed to resolve server 'EXAMPLE.EXAMPLE.COM': Domain name not found

(Thu Aug 31 09:16:17 2017) [sssd[be[]]] [set_server_common_status] (0x0100): Marking server 'EXAMPLE.EXAMPLE.COM' as 'not working'

(Thu Aug 31 09:16:17 2017) [sssd[be[]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (EXAMPLE.EXAMPLE.COM), resolver returned [11]: Resource temporarily unavailable

On 08/31/2017 04:38 PM, Michal Židek wrote:
I forgot to say one think. You can sanitize the logs, but please
sent the whole logs (not just parts) for the sssd_domain and
sssd_nss logs (maybe you actually did this, but as I said,
I do not see the mail with the attachment).


On 08/31/2017 04:31 PM, Michal Židek wrote:

I do not see the email where you sent the logs as attachment.
Maybe it is stuck in moderation (maybe the attachment was too big
or something). I only noticed you sent something thanks to your
last message. Can you please sent the logs directly to me?

If the logs are too big, It will help if you stop sssd, delete the logs, start sssd again and redo the test. This will keep the logs shorter.



On 08/31/2017 03:45 PM, William Edsall wrote:
Further testing I think user1 may have been cached all along. I was not clearing cache while sssd was stopped.

After stopping, clearing, starting - id user1 hangs. I then add ad_server and debug_level to sssd.conf and restart it. I can now id user1 but I believe it's coming from cache.

On Thu, Aug 31, 2017 at 9:28 AM, William Edsall < <>> wrote:

      left realm, joined realm as user1, added debug_level and ad_server
    to sssd.conf (it seems to hang when it runs into a dead ad_server),
    restarted nssd.

    I ran an id on user1, it returned data. No data for user2.

    I then cleared cache using: sss_cache -E, id'ed user1 again and data
    was returned. Still no data for user2.

    domains = <>
    default_domain_suffix = <>
    config_file_version = 2
    services = nss, pam

    [domain/ <>]
    debug_level = 9
    ad_domain = <>
    krb5_realm = EXAMPLE.COM <http://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 = True
    fallback_homedir = /home/%u@%d
    access_provider = ad

    sssd_nss is ~700 of the following lines:
    (Thu Aug 31 09:21:05 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010):
    The Data Provider returned an error
    [org.freedesktop.sssd.Error.DataProvider.Offline] (attached).

    On Thu, Aug 31, 2017 at 7:44 AM, Michal Židek <
    <>> wrote:

        On 08/30/2017 09:49 PM, William Edsall wrote:

            Hello list,
               I've configured sssd on Centos 7 with the very basics.
            I'm able to id my own user account, which was used to join
            the domain (via realm), but unable to id any other account.
               Does anything make sense about this? I should mention
            this is a very large  (50,000+) corporate AD.



        please provide sssd domain and sssd_nss logs with debug_level = 9
        as well as your SSSD configuration file.

        For more details see:

        sssd-users mailing list --
        To unsubscribe send an email to

sssd-users mailing list --
To unsubscribe send an email to

sssd-users mailing list --
To unsubscribe send an email to
sssd-users mailing list --
To unsubscribe send an email to
sssd-users mailing list --
To unsubscribe send an email to