I can't replicate that "duplicate domains" situation any more.  (I thought
I'd saved that sssd.conf file, but it doesn't exhibit the same behaviour).

Here are the logs for a specific account failing to look up all groups with
ldap_use_tokengroups = True.

Logs are at this URL:
   https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0

I have included the realmd.conf, sssd.conf and krb5.conf as well.

Here's (incorrect) result back from sssd with ldap_use_tokengroups = True

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),1010(amerunixusers)

Here is correct result back when ldap_use_tokengropus = False:

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup)

this is sssd version 1.16.0

Spike




On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek <jhro...@redhat.com> wrote:

>
>
> > On 13 Jul 2018, at 17:40, Spike White <spikewhit...@gmail.com> wrote:
> >
> > Jakub,
> >
> > Thank you to answering so promptly.
> >
> > We are currently testing this in a lab before full deployment, so I have
> some degree of time before we deploy sssd in a bigger context.  If you
> would prefer for me to work with you directly off-line, please advise.  As
> an example, the attached sssd_amer.dell.com.log file was originally 40 MB.
> (I presume because of debugging level).  Out of respect for others on the
> mailing list, I severely trimmed the log file to only the lines of interest
> (I hope).  But it's entirely possible I may have over-trimmed.
> >
>
> I’m afraid so, because the logs say:
>
> (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range]
> (0x2000): No sub-attributes for [tokenGroups]
> ….
>
> and I’m really interested in this part :-)
>
> (Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]]
> [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [
> admpatrick_whee...@amer.dell.com]
> ...
> (Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]]
> [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN
> [CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use
> associated map
>
>
> > You asked:
> >     Can you send logs for a single lookup of "id username" with
> tokengroups enabled?
> >
> > Attached are the logs.  sssd_amer.dell.com.log and sssd_nss.log, for
> this lookup:
> >
> >    [root@spikerealmd02 sssd]# id admpatrick_wheeler
> >    uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
> groups=2604370(admpatrick_wheeler),1010(amerunixusers)
> >
> > This is with ldap_use_tokengroups = True, so the above lookup is
> incorrect.
> >
> > What it should show is:
> >  id admpatrick_wheeler
> > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
> groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
> >
> > You asked:
> >    Why do you disable the subdomains provider? Isn't it easier to just
> list
> >    the domains you want to enable using the ad_enabled_domains option?
> >
> >    btw this can actually cause issues because the subdomains provider is
> >    needed to fetch the joined domain SID at least, among other things.
> >
> > When I ran with:
> >       ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
> japn.dell.com, dell.com
> >
> > it broke cross-subdomain authentication.  that is, I could resolve
> accounts from the local domain (AMER), but not from any other domain (like
> apac).  When I reviewed the logs, I saw the sssd_nss.log would do a
> dispatch to the apac.dell.com child, but the dispatch would always fail.
> >
> > In sssd_apac.dell.com.log -- the dispatch was never picked up.
>
> Interesting, do you still have the logs around?
>
> >
> > I also noticed that sssctl domain-list gave me this:
> > amer.dell.com
> > apac.dell.com
> > emea.dell.com
> > japn.dell.com
> > dell.com
> > amer.dell.com
> > apac.dell.com
> > emea.dell.com
> > japn.dell.com
>
> Including the duplicate domains? That sounds like a bug..
>
> >
> > I suspect that sssd_nss was attempting to dispatch into this
> apac.dell.com "ghost" domain and failing.  When I removed
> ad_enabled_domains (& commented out dell.com as a domain), I noticed
> sssctl domain-list gave me the expected:
> >
> > amer.dell.com
> > apac.dell.com
> > emea.dell.com
> > japn.dell.com
> >
> > And cross-subdomain authentication worked (modulo this tokengroups
> problem where not all groups show up when tokengroups == True).
> >
> > You stated:
> > > ldap_schema = rfc2307bis
> >
> > Please don't set ldap_schema to anything else than 'ad' (the default)
> with id_provider=ad.
> >
> > Unfortunately, our erstwhile AD administrators when they extended our AD
> schema years ago did not use an rfc2307 schema extension.  They used a
> rfc2307bis schema extension instead.
> >
> > I had fits with even basic sssd AD integration until I realized this.
> (I thought I was going to have to manually set up ldap_filters for the few
> quirky LDAP attributes associated with an account, but then I realized this
> conformed 100% to rfc2307bis.) When I set ldap_schema to rfc2307bis, the
> basic (same domain) authentication worked (without tokengroups).
> >
>
> I meant something else. Internally in SSSD, ldap_schema=ad is a superset
> of rfc2307bis with some defaults tuned to be AD-specific. And the AD
> provider really does not expect the schema to be set to anything else,
> moreover there are some branches in the underlying LDAP provider (the AD
> provider is a wrapper around the LDAP provider more or less) that check if
> the schema is set to “ad” to follow some AD specific branch.
>
> > Spike
> >
> > On Tue, Jul 10, 2018 at 9:59 AM Jakub Hrozek <jhro...@redhat.com> wrote:
> > On Mon, Jul 09, 2018 at 03:11:38PM -0500, Spike White wrote:
> > > All,
> > >
> > > Below is a writeup of missing AD groups for accounts when using
> > > tokengroups.  When not using tokengroups, sssd is rock solid.
> > >
> > > Yes, most of the missing AD groups are universal or global groups --
> but
> > > not all!  For some accounts, even domain-local AD groups are missed
> from
> > > their group memberships.  (when using tokengroups).
> >
> > [...]
> >
> > > tokengroups-disabled SSSD:
> > >
> > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
> > >
> groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1010(amerunixusers),1003(amerlinuxsup),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport)
> > >
> > >
> > >
> > > vas:
> > >
> > > uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
> > > groups=2604370(admpatrick_wheeler),
> > > 1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
> > >
> > >
> > >
> > > diff is:
> > >
> > > 1033(amer_server_mgmt)
> > >
> > > 1003(amerlinuxsup)
> > >
> > >
> > >
> > > amer_server_mgmt is an AMER global group with GID 1033.  <--- why is
> sssd
> > > not reporting this?!?
> >
> > Can you send logs for a single lookup of "id username" with tokengroups
> > enabled?
> >
> > >
> > > amerlinuxsup is an AMER universal group with GID 1003.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Here is my /etc/sssd/sssd.conf file:
> > >
> > > [nss]
> > > debug_level = 9
> > > filter_groups = root
> > > filter_users = root
> > > #entry_cache_timeout = 300
> > > entry_cache_nowait_percentage = 75
> > >
> > > [sssd]
> > > debug_level = 6
> > > #domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com,
> dell.com
> > > domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
> > > # Unnecessary.  If missing, will search in order specified in "domains"
> > > lines above.
> > > #domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com
> ,
> > > japn.dell.com, dell.com
> > > config_file_version = 2
> > > services = nss,pam
> > > reconnection_retries = 3
> > > #ldap_user_member_of = member
> > >
> > > [pam]
> > > pam_verbosity = 3
> > > debug_level = 9
> > >
> > > [domain/amer.dell.com]
> > > debug_level = 9
> > > id_provider = ad
> > > access_provider = simple
> > > #access_provider = ad
> > > auth_provider = ad
> > > ad_domain = amer.dell.com
> > > krb5_realm = AMER.DELL.COM
> > > default_shell = /bin/bash
> > > #use_fully_qualified_names = False
> > > ldap_id_mapping = False
> > > subdomains_provider = none
> >
> > Why do you disable the subdomains provider? Isn't it easier to just list
> > the domains you want to enable using the ad_enabled_domains option?
> >
> > btw this can actually cause issues because the subdomains provider is
> > needed to fetch the joined domain SID at least, among other things.
> >
> > I would change this to:
> > ad_enabled_domains = amer.dell.com
> >
> > >
> > > auto_private_groups = True
> > > realmd_tags = joined-with-adcli
> > > cache_credentials = True
> > > krb5_store_password_if_offline = True
> > > fallback_homedir = /home/%u
> > > ldap_schema = rfc2307bis
> >
> > Please don't set ldap_schema to anything else than 'ad' (the default)
> > with id_provider=ad. We should probably just disallow changing the
> > schema in the code completely.
> >
> > > ldap_sasl_authid = host/spikerealmd02.us.dell....@amer.dell.com
> > > #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM
> > > #ldap_sasl_authid = spikerealm...@amer.dell.com
> > > #TEST REMOVAL. July 4 2018. SW
> > > #ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com,
> > > japn.dell.com,dell.com
> > > dyndns_update = False
> > > # TEST -- commented out July 4 to not use tokengroups.
> > > ldap_use_tokengroups = False
> > > simple_allow_groups = amerlinux...@amer.dell.com,
> amerlinux...@amer.dell.com,
> > > emealinux...@emea.dell.com, AMER.DELL.COM, emealinux...@emea.dell.com,
> > > apaclinux...@emea.dell.com, apaclinux...@emea.dell.com
> > >
> > > # also look at
> > >
> https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.html
> > >
> > > [domain/apac.dell.com]
> > > debug_level = 9
> > > auto_private_groups = True
> > > #use_fully_qualified_names = False
> > > ad_domain = apac.dell.com
> > > krb5_realm = APAC.DELL.COM
> > > cache_credentials = True
> > > id_provider = ad
> > > auth_provider = ad
> > > krb5_store_password_if_offline = True
> > > default_shell = /bin/bash
> > > ldap_id_mapping = False
> > > fallback_homedir = /home/%u
> > > access_provider = simple
> > > ldap_schema = rfc2307bis
> > > ldap_sasl_authid = host/spikerealmd02.us.dell....@amer.dell.com
> > > #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM
> > > #ldap_sasl_authid = spikerealm...@amer.dell.com
> > > #TEST REMOVAL. July 4 2018. SW
> > > #ad_enabled_domains = amer.dell.com, apac.dell.com, apac.dell.com,
> > > japn.dell.com, dell.com
> > > dyndns_update = False
> > > subdomains_provider = none
> > > # TEST -- commented out July 4 to not use tokengroups.
> > > ldap_use_tokengroups = False
> > > simple_allow_groups = apaclinux...@apac.dell.com,
> apaclinux...@apac.dell.com
> > >
> > > [domain/emea.dell.com]
> > > debug_level = 9
> > > auto_private_groups = True
> > > #use_fully_qualified_names = False
> > > ad_domain = emea.dell.com
> > > krb5_realm = EMEA.DELL.COM
> > > cache_credentials = True
> > > id_provider = ad
> > > auth_provider = ad
> > > krb5_store_password_if_offline = True
> > > default_shell = /bin/bash
> > > ldap_id_mapping = False
> > > fallback_homedir = /home/%u
> > > access_provider = simple
> > > ldap_schema = rfc2307bis
> > > ldap_sasl_authid = host/spikerealmd02.us.dell....@amer.dell.com
> > > #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM
> > > #ldap_sasl_authid = spikerealm...@amer.dell.com
> > > #TEST REMOVAL. July 4 2018. SW
> > > #ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
> > > japn.dell.com, dell.com
> > > dyndns_update = False
> > > subdomains_provider = none
> > > # TEST -- commented out July 4 to not use tokengroups.
> > > ldap_use_tokengroups = False
> > > simple_allow_groups = emealinux...@emea.dell.com,
> emealinux...@emea.dell.com
> > >
> > > [domain/japn.dell.com]
> > > debug_level = 9
> > > auto_private_groups = True
> > > #use_fully_qualified_names = False
> > > ad_domain = japn.dell.com
> > > krb5_realm = JAPN.DELL.COM
> > > cache_credentials = True
> > > id_provider = ad
> > > auth_provider = ad
> > > krb5_store_password_if_offline = True
> > > default_shell = /bin/bash
> > > ldap_id_mapping = False
> > > fallback_homedir = /home/%u
> > > access_provider = simple
> > > ldap_schema = rfc2307bis
> > > ldap_sasl_authid = host/spikerealmd02.us.dell....@amer.dell.com
> > > #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM
> > > #ldap_sasl_authid = spikerealm...@amer.dell.com
> > > #TEST REMOVAL. July 4 2018. SW
> > > #ad_enabled_domains = amer.dell.com, apac.dell.com, japn.dell.com,
> > > japn.dell.com, dell.com
> > > dyndns_update = False
> > > subdomains_provider = none
> > > # TEST -- commented out July 4 to not use tokengroups.
> > > ldap_use_tokengroups = False
> > > simple_allow_groups = japnlinux...@japn.dell.com,
> japnlinux...@japn.dell.com
> >
> > > _______________________________________________
> > > 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://getfedora.org/code-of-conduct.html
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/HKWYWX7MR57HRIPWJW25FK35CZMHZEJQ/
> > _______________________________________________
> > 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://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/VJFDAHDRDQPRW6WXT5MZA5KQHSW4KMEQ/
> >
> <sssd_amer.dell.com.log><sssd_nss.log>_______________________________________________
> > 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://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/MALPUOXZFB7VTK6JZCGGIKZTIXHFMJZU/
> _______________________________________________
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/SRT5K7VHD654TOEJTXZW5HH53VQTYA4A/
>
_______________________________________________
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/TDMIDKUPYNDITEMCO7BXVNAVGRUVNGHW/

Reply via email to