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(a)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(a)hostopia.com
> > uid=100001158(ezaporozhets)*gid=1004* groups=*1004*,1102
>
>
> > root@snoopy[/etc/sssd]#
*getent -s sss group
> > development-wholesale(a)hostopia.com*
> > development-wholesale:*:1004:ezaporozhets,alyubyanitskiy
>
> > root@snoopy[/etc/sssd]# id ezaporozhets(a)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(a)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(a)redhat.com
> wrote:
> > >
> > >
> > > > > On 13 Jul 2018, at 17:40, Spike White
<spikewhitetx(a)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(a)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(a)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(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = spikerealmd02(a)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(a)AMER.DELL.COM,
> amerlinuxeng(a)AMER.DELL.COM,
> > > > > > emealinuxsup(a)EMEA.DELL.COM,
AMER.DELL.COM,
> emealinuxeng(a)EMEA.DELL.COM,
> > > > > > apaclinuxsup(a)EMEA.DELL.COM, apaclinuxeng(a)EMEA.DELL.COM
> > > > >
> > > > > > # also
look at
> > > > >
>
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648....
> > > > >
> > > > > >
[
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(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = spikerealmd02(a)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(a)APAC.DELL.COM,
> apaclinuxeng(a)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(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = spikerealmd02(a)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(a)EMEA.DELL.COM,
> emealinuxeng(a)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(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
> > > > > > #ldap_sasl_authid = spikerealmd02(a)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(a)JAPN.DELL.COM,
> japnlinuxeng(a)JAPN.DELL.COM
> > > > > > _______________________________________________
> > > > > > sssd-users mailing list --
sssd-users(a)lists.fedorahosted.org
> > > > > > To unsubscribe send an email to
> sssd-users-leave(a)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.fedorahost...
> > > > > _______________________________________________
> > > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > > > To unsubscribe send an email to
> sssd-users-leave(a)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.fedorahost...
> > > >
>
<sssd_amer.dell.com.log><sssd_nss.log>_______________________________________________
> > > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > > > To unsubscribe send an email to
> sssd-users-leave(a)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.fedorahost...
> > > > _______________________________________________
> > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > > To unsubscribe send an email to
> sssd-users-leave(a)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.fedorahost...
> > > > _______________________________________________
> > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > > To unsubscribe send an email to
> sssd-users-leave(a)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.fedorahost...
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > To unsubscribe send an email to
> sssd-users-leave(a)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.fedorahost...
> >
>
>
_______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahost...