Sorry, I accidentally did not reply to the list, so, for others,
see the message below.

Michal

On 09/01/2017 04:15 PM, Michal Židek wrote:
Hi again!

See comments inline...

On 09/01/2017 03:33 PM, 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.

The logs you sent privately to me last time where from an
attempt with manually set ad_server option? It would explain
why the kerberos authentication was broken for the SSSD host
if the server you specified was different then the one
from which you downloaded the keytab entries during realm join.
This is logical, because joining machine to a realm also
involves creating host entry in the AD. This change was
not synchronized with other DCs and thus you were not able
to authenticate against them.


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 <http://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]


This is OK. In order to get all your nested group IDs, SSSD has to go
through all the members of groups that you are member of. It will not
download all users, just information about the memberships and store
them in local database, but the group needs to be stored complete
(with all memberships). So what you see being stored is the info
about the memberships, not the actual user entry from AD.

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).

Sorry I do not understand from the sentence above, if ti returns
all the expected IDs or not, or what is the current problem that
you are facing.


Not sure if this helps or just muds up the issue but it's strange indeed.

On Thu, Aug 31, 2017 at 10:47 AM, Michal Židek <mzi...@redhat.com <mailto:mzi...@redhat.com>> 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
    <http://EXAMPLE.EXAMPLE.COM> from the machine
    with SSSD?

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

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

    (Thu Aug 31 09:16:17 2017) [sssd[be[example.com
    <http://example.com>]]] [be_resolve_server_process] (0x0080):
    Couldn't resolve server (EXAMPLE.EXAMPLE.COM
    <http://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).

        Michal

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

            Hi,

            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.

            Thanks,

            Michal

            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
                <weds...@gmail.com <mailto:weds...@gmail.com>
                <mailto:weds...@gmail.com <mailto:weds...@gmail.com>>>
                wrote:


                     Steps:
                       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.


                     [sssd]
                     domains = example.com <http://example.com>
                <http://example.com>
                     default_domain_suffix = example.com
                <http://example.com> <http://example.com>
                     config_file_version = 2
                     services = nss, pam


                     [domain/example.com <http://example.com>
                <http://example.com>]
                     debug_level = 9
                     ad_domain = example.com <http://example.com>
                <http://example.com>
                     ad_server = EXAMPLE.EXAMPLE.COM
                <http://EXAMPLE.EXAMPLE.COM> <http://EXAMPLE.EXAMPLE.COM>
                     krb5_realm = EXAMPLE.COM <http://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


                     Logs:
                     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]

                     sssd_example.com.log (attached).

                     On Thu, Aug 31, 2017 at 7:44 AM, Michal Židek
                <mzi...@redhat.com <mailto:mzi...@redhat.com>
                     <mailto:mzi...@redhat.com
                <mailto:mzi...@redhat.com>>> 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.

                             Thanks
                             William



                         Hello,

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

                         For more details see:
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html <https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html> <https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html <https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html>>

                         Michal
                         _______________________________________________
                         sssd-users mailing list --
                sssd-users@lists.fedorahosted.org
                <mailto:sssd-users@lists.fedorahosted.org>
                         <mailto:sssd-users@lists.fedorahosted.org
                <mailto:sssd-users@lists.fedorahosted.org>>
                         To unsubscribe send an email to
                sssd-users-le...@lists.fedorahosted.org
                <mailto:sssd-users-le...@lists.fedorahosted.org>
                         <mailto:sssd-users-le...@lists.fedorahosted.org
                <mailto:sssd-users-le...@lists.fedorahosted.org>>





                _______________________________________________
                sssd-users mailing list --
                sssd-users@lists.fedorahosted.org
                <mailto:sssd-users@lists.fedorahosted.org>
                To unsubscribe send an email to
                sssd-users-le...@lists.fedorahosted.org
                <mailto:sssd-users-le...@lists.fedorahosted.org>

            _______________________________________________
            sssd-users mailing list -- sssd-users@lists.fedorahosted.org
            <mailto:sssd-users@lists.fedorahosted.org>
            To unsubscribe send an email to
            sssd-users-le...@lists.fedorahosted.org
            <mailto:sssd-users-le...@lists.fedorahosted.org>

        _______________________________________________
        sssd-users mailing list -- sssd-users@lists.fedorahosted.org
        <mailto:sssd-users@lists.fedorahosted.org>
        To unsubscribe send an email to
        sssd-users-le...@lists.fedorahosted.org
        <mailto:sssd-users-le...@lists.fedorahosted.org>

    _______________________________________________
    sssd-users mailing list -- sssd-users@lists.fedorahosted.org
    <mailto:sssd-users@lists.fedorahosted.org>
    To unsubscribe send an email to
    sssd-users-le...@lists.fedorahosted.org
    <mailto:sssd-users-le...@lists.fedorahosted.org>




_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

Reply via email to