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).
*Missing group memberships with sssd (when using tokengroups):*
July, 2018.
Cross-subdomain AD authentication partially working. (fully working with ldap_use_tokengroups = False)
When set ldap_use_tokengroups = True, some AD groups for some accounts missing. Full details below.
Test server is in AMER.DELL.COM
*Accounts and their missing AD group memberships (when ldap_use_tokengroups = True)*
*AdmJesse_Chan *(account resides in APAC.DELL.COM)
tokengroups-enabled SSSD reports membership in:
uid=525641(admjesse_chan) gid=525641(admjesse_chan) groups=525641(admjesse_chan),1008(apacunixusers),1000(apaclinuxeng),1001(apaclinuxsup)
vas-enabled Linux server reports membership in:
uid=525641(admjesse_chan) gid=525641(admjesse_chan) groups=525641(admjesse_chan),1000(apaclinuxeng),1001(apaclinuxsup),1008(apacunixusers), 1041(linux-core-engineering),1069(users)
diff is:
1041(linux-core-engineering),1069(users)
Both are AMER-only "local domain" groups.
linux-core-engineering is a AMER-only "domain local" group with GID 1041.
And actually, admjesse_chan is a member of 'users', but that's an APAC.DELL.COM domain AD group (that's not unix-enabled).
VAS is (mistakenly) reporting Jesse as a member of the AMER.DELL.COM 'users' group, which has a GID of 1069.
*AdmPaulBowen *(account resides in EMEA.DELL.COM)
tokengroups-enabled SSSD reports membership in:
uid=2103156(admpaul_bowen) gid=2103156(admpaul_bowen) groups=2103156(admpaul_bowen),1009(emeaunixusers)
vas-enabled Linux server reports membership in:
uid=2103156(admpaul_bowen) gid=2103156(admpaul_bowen) groups=2103156(admpaul_bowen),1153(emea_server_mgmt),1005(emealinuxsup) ,1009(emeaunixusers)
diff is:
1153(emea_server_mgmt),1005(emealinuxsup),
EMEA_SERVER_MGMT is a universal AD group. with GID 1153.
EMEALINUXSUP is a universal AD group. with GID 1005.
EMEAUNIXUSERS is a global AD group. with GID 1009.
*AdmDennis_Kennedy* (account resides in EMEA.DELL.COM)
tokengroups-enabled SSSD:
uid=2890335(admdennis_kennedy) gid=2890335(admdennis_kennedy) groups=2890335(admdennis_kennedy),1009(emeaunixusers)
vas:
uid=2890335(admdennis_kennedy) gid=2890335(admdennis_kennedy) groups=2890335(admdennis_kennedy),1153(emea_server_mgmt),1004(emealinuxeng), 1009(emeaunixusers),1041(linux-core-engineering)
diff:
1153(emea_server_mgmt),1004(emealinuxeng),1041(linux-core-engineering)
EMEA_SERVER_MGMT is a universal AD group. with GID 1153.
EMEALINUXENG is a universal AD group. with GID 1003.
linux-core-engineering is a AMER-only "domain local" group with GID 1041.
*AdmSpike_White* (account resides in AMER.DELL.COM)
tokengroups-enabled SSSD:
uid=2025431(admspike_white) gid=2025431(admspike_white) groups=2025431(admspike_white),1002(amerlinuxeng)
vas:
uid=2025431(admspike_white) gid=2025431(admspike_white) groups=2025431(admspike_white),1002(amerlinuxeng), 1041(linux-core-engineering),1069(users)
diff:
1041(linux-core-engineering),1069(users)
linux-core-engineering is a AMER-only "domain local" group with GID 1041.
users is an AMER-only "builtin local" group with GID 1069.
*AdmCesar_Guillen* (account found in AMER.DELL.COM)
NOTE: AdmCesar_Guillen is found in AMERICAS.
tokengroups-enabled SSSD:
uid=2669411(admcesar_guillen) gid=2669411(admcesar_guillen) groups=2669411(admcesar_guillen),1010(amerunixusers)
vas:
uid=2669411(admcesar_guillen) gid=2669411(admcesar_guillen) groups=2669411(admcesar_guillen),1033(amer_server_mgmt),1002(amerlinuxeng) ,1010(amerunixusers),2284031(esg_bios_code_rw)
diff:
1033(amer_server_mgmt),1002(amerlinuxeng),2284031(esg_bios_code_rw)
amer_server_mgmt is an AMER global group with GID 1033. <--- why is sssd not reporting this?!?
amerlinuxeng is a universal AD group with GID 1002. <---------- why is sssd not reporting this?!? It's reported for AdmSpike_White, but not for AdmPatrick_Wheeler or AdmCesar_Guillen.
esg_bios_code_rw is a universal AD group with GID 2284031. <---------- why is sssd not reporting this?!?
*Admpatrick_wheeler* (account resides in AMER.DELL.COM)
tokengroups-enabled SSSD:
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers)
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?!?
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
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 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
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....
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.
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.
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
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).
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....
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....
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....
On 22 Jul 2018, at 20:49, Spike White spikewhitetx@gmail.com wrote:
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)
Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name.
So I think there are three options: 1) add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug.. 2) try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option 3) just use tokengroups=false as a workaround.
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
Thanks, this is more helpful
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.... _______________________________________________ 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....
I am seeing similar issues on CentOS 7, where groups, including primary group, cannot be looked up. This is really bad when other services depend on group lookups, for example sshd match group statements for enabling tcpforwarding which otherwise is disable globally, iptables group lookups ( yes, I use both ).
[root@snoopy ~]$ rpm -q sssd sssd-1.16.0-19.el7_5.5.x86_64
root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004* groups=*1004*,1102
root@snoopy[/etc/sssd]# *getent -s sss group development-wholesale@hostopia.com* development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004(development-wholesale) **groups=1004(development-wholesale),1102*
I tried setting ldap_use_tokengroups = false at domain level, however still seeing the issue. I use ldap provider.
Thank you
On 07/23/2018 04:13 AM, Jakub Hrozek wrote:
On 22 Jul 2018, at 20:49, Spike White spikewhitetx@gmail.com wrote:
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)
Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name.
So I think there are three options:
- add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug..
- try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option
- just use tokengroups=false as a workaround.
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
Thanks, this is more helpful
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.... _______________________________________________ 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....
Perhaps this is a caching issue? I do have several domains configured, and each domain has development-wholesale name with different GID. Is the domains cache configured/hased based on the group name ? Thanks
On 07/23/2018 12:05 PM, Mario Rossi wrote:
I am seeing similar issues on CentOS 7, where groups, including primary group, cannot be looked up. This is really bad when other services depend on group lookups, for example sshd match group statements for enabling tcpforwarding which otherwise is disable globally, iptables group lookups ( yes, I use both ).
[root@snoopy ~]$ rpm -q sssd sssd-1.16.0-19.el7_5.5.x86_64
root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004* groups=*1004*,1102
root@snoopy[/etc/sssd]# *getent -s sss group development-wholesale@hostopia.com* development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004(development-wholesale) **groups=1004(development-wholesale),1102*
I tried setting ldap_use_tokengroups = false at domain level, however still seeing the issue. I use ldap provider.
Thank you
On 07/23/2018 04:13 AM, Jakub Hrozek wrote:
On 22 Jul 2018, at 20:49, Spike Whitespikewhitetx@gmail.com wrote:
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)
Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name.
So I think there are three options:
- add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug..
- try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option
- just use tokengroups=false as a workaround.
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
Thanks, this is more helpful
On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozekjhrozek@redhat.com wrote:
On 13 Jul 2018, at 17:40, Spike Whitespikewhitetx@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 Hrozekjhrozek@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 tosssd-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 tosssd-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 tosssd-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 tosssd-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 tosssd-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 tosssd-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....
On Mon, Jul 23, 2018 at 12:05:49PM -0400, Mario Rossi wrote:
I am seeing similar issues on CentOS 7, where groups, including primary group, cannot be looked up. This is really bad when other services depend on group lookups, for example sshd match group statements for enabling tcpforwarding which otherwise is disable globally, iptables group lookups ( yes, I use both ).
[root@snoopy ~]$ rpm -q sssd sssd-1.16.0-19.el7_5.5.x86_64
root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004* groups=*1004*,1102
root@snoopy[/etc/sssd]# *getent -s sss group development-wholesale@hostopia.com* development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004(development-wholesale) **groups=1004(development-wholesale),1102*
I tried setting ldap_use_tokengroups = false at domain level, however still seeing the issue. I use ldap provider.
Then tokengroups are not relevant at all, it's an AD provider option primarily.
I would suggest to gather the logs (and even better, start a separate thread so the two don't mixed up..)
Thank you
On 07/23/2018 04:13 AM, Jakub Hrozek wrote:
On 22 Jul 2018, at 20:49, Spike White spikewhitetx@gmail.com wrote:
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)
Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name.
So I think there are three options:
- add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug..
- try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option
- just use tokengroups=false as a workaround.
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
Thanks, this is more helpful
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.... _______________________________________________ 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....
Jakub,
You said:
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)
Thank you, now the logs are more helpful. What I see is repetition of “cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name.
So I think there are three options: 1) add ad_enabled_domains=$self to each of the domains, e.g. add ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug.. 2) try to help sssd by setting the domain SID manually with the ldap_idmap_default_domain_sid option 3) just use tokengroups=false as a workaround.
Certainly option 3 works. Flawlessly. But if I'm going to deploy sssd big-time (like I plan to), I would prefer for it to have all possible optimizations. Including tokengroups. (although we don't use nested subgroups very much at all).
So I tried option 1. Here is result:
[root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
It's better. It found 3 of his 15 AD groups.
Here's the link that contains all the logs, plus all the *.conf files.
https://www.dropbox.com/sh/vk9ezo82nw5xdp5/AADKSaCg_QQ2Bb-bAuZdJe-Ia?dl=0
I don't fully understand option 2.
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),228362 3(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
Thanks, this is more helpful
This is still what sssd should be returning. This is from sssd, option 3 (no tokengroups).
Spike
On Mon, Jul 23, 2018 at 2:16 PM Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Jul 23, 2018 at 12:05:49PM -0400, Mario Rossi wrote:
I am seeing similar issues on CentOS 7, where groups, including primary group, cannot be looked up. This is really bad when other services
depend on
group lookups, for example sshd match group statements for enabling tcpforwarding which otherwise is disable globally, iptables group
lookups (
yes, I use both ).
[root@snoopy ~]$ rpm -q sssd sssd-1.16.0-19.el7_5.5.x86_64
root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*;
service
sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004* groups=*1004*,1102
root@snoopy[/etc/sssd]# *getent -s sss group development-wholesale@hostopia.com* development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
root@snoopy[/etc/sssd]# id ezaporozhets@hostopia.com uid=100001158(ezaporozhets)*gid=1004(development-wholesale) **groups=1004(development-wholesale),1102*
I tried setting ldap_use_tokengroups = false at domain level, however
still
seeing the issue. I use ldap provider.
Then tokengroups are not relevant at all, it's an AD provider option primarily.
I would suggest to gather the logs (and even better, start a separate thread so the two don't mixed up..)
Thank you
On 07/23/2018 04:13 AM, Jakub Hrozek wrote:
On 22 Jul 2018, at 20:49, Spike White spikewhitetx@gmail.com
wrote:
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)
Thank you, now the logs are more helpful. What I see is repetition of
“cant find domain for $SID”. And I believe this is because the subdomains provider is disabled, because (quite confusingly) the subdomains provider is also responsible for fetching information about the joined domain, like its SID or the NetBIOS name.
So I think there are three options:
- add ad_enabled_domains=$self to each of the domains, e.g. add
ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make sssd fetch info about that domain only. I know you wrote earlier that this gave you some other headaches, but if it does, then there’s another bug..
- try to help sssd by setting the domain SID manually with the
ldap_idmap_default_domain_sid option
- just use tokengroups=false as a workaround.
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
Thanks, this is more helpful
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_domainsoption?
btw this can actually cause issues because the subdomainsprovider is
needed to fetch the joined domain SID at least, among otherthings.
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....
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-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@lists.fedorahosted.org
-
Jakub Hrozek -
Mario Rossi -
Spike White