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 jhrozek@redhat.com wrote:
On 13 Jul 2018, at 17:40, Spike White spikewhitetx@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_Wheeler@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 jhrozek@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.com@AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM #ldap_sasl_authid = spikerealmd02@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 = amerlinuxsup@AMER.DELL.COM,
amerlinuxeng@AMER.DELL.COM,
emealinuxsup@EMEA.DELL.COM, AMER.DELL.COM, emealinuxeng@EMEA.DELL.COM, apaclinuxsup@EMEA.DELL.COM, apaclinuxeng@EMEA.DELL.COM
# also look at
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.htm...
[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.com@AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM #ldap_sasl_authid = spikerealmd02@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 = apaclinuxsup@APAC.DELL.COM,
apaclinuxeng@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.com@AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM #ldap_sasl_authid = spikerealmd02@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 = emealinuxsup@EMEA.DELL.COM,
emealinuxeng@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.com@AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$@AMER.DELL.COM #ldap_sasl_authid = spikerealmd02@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 = japnlinuxsup@JAPN.DELL.COM,
japnlinuxeng@JAPN.DELL.COM
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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....
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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....
<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-leave@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.... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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....